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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document is part of a series of documents that specify charging functionality and charging management in 
GSM/UMTS networks. The GSM/UMTS core network charging architecture and principles are specified in 
3GPP TS 32.240 [1], which provides an umbrella for other charging management TSs that specify: 

• the content of the CDRs per domain and subsystem (offline charging); 

• the content of real-time charging messages per domain / subsystem (online charging); 

• the functionality of online and offline charging for those domains and subsystems; 

• the interfaces that are used in the charging framework to transfer the charging information (i.e. CDRs or 
charging events). 

The complete document structure for these TSs is defined in 3GPP TS 32.240 [1]. 

The present document specifies the Offline Charging description for the 3GPP Circuit Switched domain, based on the 
functional descriptions of the 3GPP bearer-, tele- and supplementary services in 3GPP TS 22.002 [200], 
3GPP TS 22.003 [201] and 3PP TS 22.004 [202], respectively. This charging description includes the offline charging 
architecture and scenarios specific to the CS domain, as well as the mapping of the common charging architecture 
specified in 3GPP TS 32.240 [1] onto the CS domain. It further specifies the structure and content of the CDRs for 
offline charging. The present document is related to other 3GPP charging TSs as follows: 

• The common 3GPP charging architecture is specified in 3GPP TS 32.240 [1]; 

• The parameters, abstract syntax and encoding rules for these CDR types are specified in 3GPP TS 32.298 [51]. 

• The file based mechanism used to transfer the CDRs from the network to the operator's billing domain (e.g. the 
bilUng system or a mediation device) is specified in 3GPP TS 32.297 [52]. 

Note that onhne charging for the CS domain is solely based on CAMEL (3GPP TS 23.078 [207] and 
3GPP TS 29.078 [213]) and therefore outside the scope of the 32 series of charging specifications. 

All terms, definitions and abbreviations used in the present document, that are common across 3GPP TSs, are defined in 
3GPP TR 21.905 [100]. Those that are common across charging management in GSM/UMTS domains, services or 
subsystems are provided in the umbrella document 3GPP TS 32.240 [1] and are copied into clause 3 of the present 
document for ease of reading. Finally, those items that are specific to the present document are defined exclusively in 
the present document. 

Furthermore, requirements that govern the charging work are specified in 3GPP TS 22.1 15 [102]. 
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3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [50], 3GPP TS 32.240 [1] 
and the following apply: 

accounting: process of apportioning charges between the Home Environment, Serving Network and User 

advice of charge: real-time display of the network utilization charges incurred by the Mobile Station 

The charges are displayed in the form of charging units. If a unit price is stored by the MS then the display may also 

include the equivalent charge in the home currency. 

Advice of Charge (AoC) service: combination of one or more services, both basic and supplementary, together with a 
number of other charging relevant parameters to define a customized service for the purpose of Advice of Charge 

billing: function whereby CDRs generated by the charging function are transformed into bills requiring payment 

Billing Domain: part of the operator network, which is outside the core network, that receives and processes charging 

information from the core network charging functions 

It includes functions that can provide billing mediation and billing end applications. 

CAMEL: network feature that provides the mechanisms to support operator specific services even when roaming 
outside HPLMN 

CAMEL subscription information: identifies a subscriber as having CAMEL services 

CDR field categories: Defined in 3GPP TS 32.250. They are divided into the following categories: 

• Mandatory: field that shall be present in the CDR. 

• Conditional: field that shall be present in a CDR if certain conditions are met. 

• Operator Provisionable: Mandatory: A field that operators have provisioned to be included in the CDR for all 
conditions. 

• Operator Provisionable: Conditional: A field that operators have provisioned to be included in the CDR if 
certain conditions are met. 
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Charging Data Record (CDR): record generated by a network element for the purpose of billing a subscriber for the 
provided service 

It includes fields identifying the user, the session and the network elements as well as information on the network 
resources and services used to support a subscriber session. In the traditional circuit domain, CDR has been used to 
denote "Call Detail Record", which is subsumed by "Charging Data Record" hereafter. 

charged party: user involved in a chargeable event who has to pay parts or the whole charges of the chargeable event, 
or a third party paying the charges caused by one or all users involved in the chargeable event, or a network operator 

charging: function whereby information related to a chargeable event is formatted and transferred in order to make it 
possible to determine usage for which the charged party may be billed 

charging destination: also referred to as a destination for charging, this is a nominal reference defining the point of 
termination of a connection for charging purposes 

charging origin: nominal reference defining the point of origin of a connection for charging purposes 

circuit switched domain: domain within UMTS in which information is transferred in circuit mode 

GSM only: indicates that this clause or paragraph applies only to a GSM system 
For multi-system cases this is determined by the current serving radio access network. 

inter-system change: change of radio access between different radio access technologies such as GSM and UMTS 

in GSM,...: qualifier indicating that this paragraph applies only to GSM System 

in UMTS,...: qualifier indicating that this paragraph applies only to UMTS System 

near real time: near real time charging and billing information is to be generated, processed, and transported to a 
desired conclusion in less than 1 minute 

observed IMEI ticket: record used to describe an EIR relevant event e.g. a blacklisted IMEI 

offline charging: charging mechanism where charging information does not affect, in real-time, the service rendered 

online charging: charging mechanism where charging information can affect, in real-time, the service rendered and 
therefore a direct interaction of the charging mechanism with session/service control is required 

real time: real time charging and billing information is to be generated, processed, and transported to a desired 
conclusion in less than 1 s 

successful call: connection that reaches the communication or data transfer phase e.g. the "answered" state for speech 

connections 

All other connection attempts are regarded as unsuccessful. 

tariff period: part of one (calendar) day during which a particular tariff is applied 

Defined by the time at which the period commences (the switch-over time) and the tariff to be applied after switch-over. 

tariff: set of parameters defining the network utilization charges for the use of a particular service 

UMTS only: indicates that this clause or paragraph applies only to a UMTS system 
For multi-system cases this is determined by the current serving radio access network. 

3.2 Symbols 

For the purposes of the present document, the following symbols apply: 

A Interface between an MSC and a BSC 

Be Reference point for the CDR file transfer from the Circuit Switched CGF to the BD. 

Gd Interface between an SMS-GMSC and an SGSN, and between a SMS-IWMSC and an SGSN 

Gs Interface between an SGSN and an MSC/VLR. 

lu Interface between the RNS and the core network. It is also considered as a reference point 

kbit/s Kilobits per second. 1 kbit/s = 2^^ bits per second. 

Mbit/s Megabits per second. 1 Mbit/s = 2^^ bits per second. 

Mc Interface between the MGW and (G)MSC server 
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R Reference point between a non-ISDN compatible TE and MT. Typically this reference point 

supports a standard serial interface. 

Um Interface between the Mobile Station (MS) and the GSM fixed network part. 

Uu Interface between the Mobile Station (MS) and the UMTS fixed network part. 

PS Packet Switched 

TAP Transferred Account Procedure 

CFB Call Forwarding on Busy 

CFNRY Call Forwarding on No ReplY 

ANM ANswer Message 

3.3 Abbreviations 

For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [50], 3GPP TS 32.240 [1] and 
the following apply: 

3G 3'^'^ Generation 

3GPP 3"* Generation Partnership Project 

AoC Advice of Charge 

BD Billing Domain 

BS BilHng System 

CAI Charge Advice Information 

CAMEL Customized Applications for Mobile network Enhanced Logic 

CCF Charging Collection Function 

CDF Charging Data Function 

CDR Charging Data Record 

CGF Charging Gateway Function 

CPH Call Party Handling 

CS Circuit Switched 

CTF Charging Trigger Function 

DP Detection Point 

EDP Event Detection Point 

EIR Equipment Identity Register 

EMS-Digits North American Emergency Service Routing Digits 

EMS-Key North American Emergency Service Routing Key 

FCI Furnish Charging Information 

FT AM File Transfer, Access and Management 

GMSC Gateway MSC 

gsmSCF GSM Service Control Function 

gsmSSF GSM Service Switching Function 

HLR Home Location Register 

HPLMN Home PLMN 

HSCSD High Speed Circuit Switched Data 

ICA Initiate Call Attempt 

IMEI International Mobile Equipment Identity 

IMSI International Mobile Subscriber Identity 

ISDN Integrated Services Digital Network 

ITU-T International Telecommunication Union - Telecommunications standardization sector 

JIP Jurisdiction Information Parameter 

LAC Location Area Code 

LCS Location Service 

LR Location Request 

LRN Location Routing Number 

MAP Mobile Application Part 

MLC Mobile Location Center 

MOC Mobile Originated Call (attempt) 

MO-LR Mobile Originated - Location Request 

MS Mobile Station 

MSC Mobile Switching Centre 

MSRN Mobile Station Roaming Number 

MTC Mobile Terminated Call (attempt) 

MTRF Mobile Terminating Roaming Forwarding 
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MT-LR Mobile Terminated - Location Request 

NE Network Element 

NI-LR Network Induced - Location Request 

OCS Online Charging System 

O-CSI Originating - CAMEL Subscription Information 

PLMN Public Land Mobile Network 

PSTN Public Switched Telephony Network 

RDI Restricted Digital Information 

RNC Radio Network Controller 

SAC Service Area Code 

SCF Service Control Function 

SCI Subscriber Controlled Input 

SCI Send Charging Information 

SCUDIF Service Change and UDI/RDI Fallback 

SMS Short Message Service 

SRF Specialised Resource Function 

T-CSI Terminating - CAMEL Subscription Information 

TDP Trigger Detection Point 

UI User Interaction 

UMTS Universal Mobile Telecommunications System 

USSD Unstructured Supplementary Service Data 

UDI Unrestricted Digital Information 

UTRAN Universal Terrestrial Radio Access Network 

VAS Value Added Service 

VCC Voice Call Continuity 

VLR Visitor Location Register 

VMSC Visited MSC 

VPLMN Visited PLMN 

VT-CSI Visited Terminating - CAMEL Subscription Information 
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Architecture considerations 



4.1 High level CS domain architecture 

Figure 4.1 shows the 3G logical architecture as described in 3GPP TS 23.002 [103]. Refer to 3GPP TS 23.002 [103] for 
a description of the reference points not covered in the present document. 

1. 
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Figure 4.1 : Overview of thie 2G, 3G CS and PS and E-UTRAN PS logical architecture 

The 3"* Generation Mobile system is logically implemented on the GSM/GPRS structure through the addition of a new 
air interface supported by two network nodes, the RNC and the Node B. No inference should be drawn about the 
physical configuration on an interface from figure 4. 1 . 

The CAMEL entities are not shown in figure 4. 1 . For the relationship ship of the CAMEL entities to the core network 
entities illustrated above, refer to3GPP TS 23.002 [103]. 

4.2 CS domain offline charging architecture 

Figure 4.2.1 illustrates the 3"" Generation charging logical architecture, which is subdivided by the two transmission 
planes, the Circuit Switched (CS) domain and the Packet Switched (PS) domain. The entities of the CS domain are 
encircled by the related box on the left hand side of the figure. 
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Figure 4.2.1 : 3G charging logical architecture 

The components grouped in the grey boxes constitute what was referred to as the "MSC" prior to 3GPP Release 4. The 
boxes which show red lines are those that are relevant for CS domain charging. While not shown explicitly in 
figure 4.2.1, the VLR may also generate CDRs (cf. figure 4.1 for the relationship between VLR and MSC server). In 
addition, the gsmSCF may also produce CDRs, however, these are not subject to 3GPP standardization. 
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Figure 4.2.2 specifies the mapping of the 3GPP common charging architecture, as laid down in 3GPP TS 32.240 [1], 
onto the CS domain. 

As depicted in figure 4.2.2, all charging functions (CTF, CDF and CGF) reside within each CS Network Element (i.e. 
the MSC server, the VLR, and the HLR). Thus, the CS nodes are connected directly to the Billing Domain via the Be 
reference point. This implies that there exists no separate CDF and CGF for the CS domain, and no corresponding open 
interfaces between any such functions, within the 3GPP standards. 

However, vendors may choose to implement separate CDF and CGF for the CS domain. In that case, the interfaces 
between these functions should comply with the definition of the Rf and Ga reference points (3GPP TS 32.299 [50] and 
3GPP TS 32.295 [54], respectively) as much as possible. 
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Figure 4.2.2: CS offline charging architecture 



4.3 CS domain online charging architecture 

CS domain online charging is implemented by CAMEL techniques as described in 3GPP TS 23.078 [207] and 
3GPP TS 29.078 [212], i.e. outside the scope of the 32 series of charging TSs. 

NOTE: that the CDRs described in the present document do contain CAMEL information. This is because some 
of that information is relevant to offline charging in case of CAMEL control of (part of) the call, and thus 
needs to be captured in the offline charging information. However, this is not related to the online 
charging functions for the CS domain. 
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5 CS domain charging principles and scenarios 

5.1 CS domain charging principles 

The following high-level requirements summarize the more detailed requirements of 3GPP TS 22.1 15 [102]. 

1. to provide a CDR for all charges incurred and requiring settlement between the different commercial roles; 

2. to allow itemized billing for all services (including CAMEL) charged to each subscription, including voice and 
data calls, and services offered by home environments, taking into account: 

information provided by the user (including authentication parameters, etc.); 

information provided by the serving network (including Serving Network Id, timestamps, etc.); 

information provided by the service (including charged party, long calling, multimedia, etc.). 

3. to allow fraud control by the Home Environment and the Serving network. 

5.1 .1 General aspects of Charging Data 

Charging Data Record (CDR) generation and contents should be flexible and unnecessary redundancy in data should be 
avoided. Charging data are collected for successful and selected unsuccessful subscriber transactions. The subscriber 
transaction is seen as being successful in the MSC server (where the CDR is generated) either if a call is answered or if 
the Short Message Service Centre has confirmed the successful receipt of a mobile originated short message. 

Unsuccessful call attempts are recorded in the case of partial record generation due to CAMEL FollowOnCalls. If in 
such a call constellation the answer state is reached at least once, subsequent unsuccessful set-up of a connection 
configuration is also recorded in order to provide a complete sequence of FIRST, INTERMEDIATE and LAST records. 

At termination of the subscriber transaction these data are formatted into CDRs. These records are forwarded onto MSC 
server's CGF which constitutes the source for further transportation of that data to the Billing Domain via the Be 
reference point, see 3GPP TS 32.297 [52]. For the purpose of the present document, the CDRs are considered to be 
collected, in near real-time, by the following network elements: the MSC servers, MGWs, and location registers 
(VLR/HLR). 

The data collected by the network elements are sent to ("pushed"), or collected by ("pulled"), the Billing Domain for 
storage and further processing. The CDR transfer across the Be reference point is specified in detail in 3GPP TS 32.297 
[52]. 

Similarly, the tariff data required by the network elements to provide on-line charging information are distributed by the 
appropriate management system. This function, however, is outside the scope of 3GPP standardization. 

5.1.2 Charging information 

The MSC server and Gateway MSC server are responsible for the collection of all charging relevant information for 
each MS and PSTN connection and for the storage of this information in the form of CDRs. 

Circuit switched calls can be charged in one MSC server (the anchor MSC server) where all relevant data is available. 
That is guaranteed by routing all signalling information though the anchor MSC server even if the traffic channel of a 
call is routed through another MSC server due to handover. 

The Gateway MSC server acts as a gateway into other PLMNs or fixed networks. Within the PLMN, the GMSC server 
is responsible for the generation of CDRs for calls routed from or into other networks. 

If subscribed CAMEL services apply to MS, the (G)MSC servers contain CAMEL subscription data providing the 
information required for invocation of the CAMEL dialogues for controlling the MS terminating and MS originating 
calls. Charging data record parameters resulting from the CAMEL treatment applying to MS calls is derived from the 
CAMEL subscription data. 
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In addition to user subscribed services, specific dialled CAMEL services might be invoked which also influence 
existing records or even trigger the generation of separate records steered by service logic. 

Each CDR captures all charging information relevant to the call, or in case of partial CDRs (see clause 5.1.3.6), the 
portion of a call that the CDR covers. Depending on the type of CDR and the node producing it, this includes 
information on tele- and bearer services (which may include radio resource usage) and supplementary service 
invocation / termination. As far as tele- and bearer services are concerned, all service information is embedded in the 
appropriate CS CDR, i.e. there are no specific "service CDRs" in the CS domain. For Supplementary Services, the exact 
treatment is specified in clause 5.1.3.3. 

In addition to the information collected from the network elements, network management functions are required for the 
administration of on-line charging data stored in the MSC servers. This data is employed to drive the charge display in 
the Mobile Station (MS) as required by the Advice of Charge (AoC) service and defined by 3GPP TS 22.086 [204] and 
3GPPTS 22.024 [203]. 

5.1.2.1 Subscriber billing 

The charging data collected from the HPLMN, interrogating PLMN, and/or VPLMN network elements is employed to 
determine the network utilization charges for the basic and supplementary services utilized by the home subscribers of 
the PLMN. The charges calculated are then combined with the network access (subscription) charges and billed to those 
customers directly serviced by the PLMN. 

For those subscribers handled by Service Providers, the billing information is employed for both wholesale (Network 
Operator to Service Provider) and retail (Service Provider to Subscriber) billing. Consequently, having been processed 
by the PLMN Billing System, the charging data collected from the network elements may also be sent to the Service 
Provider for further processing. 

5.1 .2.2 Settlements of Charges 

5.1.2.2.1 Inter-PLMN accounting 

Inter-PLMN accounts for roaming traffic are determined in accordance with ITU-T principles (see ITU-T 
Recommendation D.93 [300]) and are settled by means of the GSM Association's Transferred Account Procedure 
(TAP). 

5.1 .2.2.2 "Visitors" from other PLMNs 

The CDRs collected from the network also include details of the services employed by visiting (roaming) subscribers. 
The charges for Mobile Originated Calls (MOCs) and for supplementary services used are calculated as for home 
subscribers, converted to an agreed accounting currency and included in the CDRs for the TAP. Even if Mobile 
Terminated Calls (MTCs) are zero-priced in the visited network (VPLMN), in the absence of "optimized routing" the 
MTC TAP records are still required by the home network (HPLMN) in order to determine the re-routing charges from 
the HPLMN to the VPLMN. 

The TAP records generated are exchanged with each HPLMN on a regular basis. These TAP records form the basis of 
the invoice submitted by the VPLMN for the traffic carried. 

5.1 .2.2.3 "Home" subscribers roaming in other PLMNs 

The HPLMN receives TAP records from each VPLMN for services employed by home subscribers whilst roaming. 
These records are employed to verify the invoices from the VPLMN and to bill the home subscribers for the services 
used. The charges contained in the TAP records are converted from the accounting currency to the local currency and a 
handling surcharge (mark-up) is added if required. The TAP records are subsequently passed to the subscriber billing 
process described in clause 5.1.2.1. 

5.1 .2.2.4 Settlement with other networks 

The settlement of accounts with the operators of other networks (fixed / mobile) for traffic carried, is generally 
performed on a bulk basis according to the principles outlined in the ITU-T Recommendations D-series. 
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The traffic accounted for in this manner may include: 

outgoing (Mobile to Mobile/Land) traffic; 

incoming (Land/Mobile to Mobile) traffic; 

transit traffic, carried by intermediate networks; 

- signalhng (MAP/SCCP, CAP/SCCP) traffic such as location updates. 

Accounting information may also be required for the use of services provided by other operators such as short message 
service centres and other Value Added Service (VAS) providers. 

The charges for the various traffic shares may be determined on the basis of the CDRs generated by the network 
elements or on the basis of bulk counters (accounting meter records) in the gateway MSC servers (GMSC servers). For 
the purpose of the present document, the management information required is assumed to be derived from CDRs. The 
management of accounting meters is outside the scope of the present document. 

In GSM, the radio resources used for various connection types are roughly identical, hence no differentiation of the 
connection types is needed for the purpose of inter-network accounting. In UMTS, however, the radio bandwidth 
allocated to a connection may be much higher compared to GSM, even though the connection looks identical from the 
perspective of the gateway MSC server. Therefore it is necessary that the gateway CDRs capture the cases where 
"higher-than-normal" radio bandwidth is occupied. An example of a narrow band radio connection is the standard AMR 
voice call. An example of a wideband service, using the same landline channel but much more radio resources, is the 
use of BS30 for video telephony. 

Given that - in contrast to the serving MSC server - the gateway MSC server cannot distinguish the cases described 
above, the serving MSC server is capable of returning information on the bearer capability back to the GMSC server so 
that this information can be added to the gateway CDR for incoming connections. For further details of this 
functionality, refer to 3GPP TS 29.007 [213]. 

5.1.2.3 Service Information 

The charging data collected from the network elements may be used to provide statistical information concerning the 
use of services, by both home and visiting subscribers, within the network. In addition, the introduction of new services 
and / or modifications to the tariffs of existing services may also require the distribution of the appropriate tariff 
information to the network elements for Advice of Charge purposes. 

5.1 .3 Special cases and considerations 

The following clauses provide detailed consideration on CS domain specific items and topics. 

5.1.3.1 AoC service 

In addition to the information collected from these Network Elements, network management functions are required for 
the administration of on-line charging data stored in the MSC server. Two levels of AoC service are available: 
information level and charging level. The information level is used only to provide AoC information to the user. For the 
charging level, if no approval of the AoC information by the MS is received in the MSC server, the call is released 
immediately. 

This data is employed to drive the charge display in the Mobile Station (MS) as required by the advice of charge (AoC) 
service and defined by 3GPP TS 22.086 [64] and 3GPP TS 22.024 [63]. Information used by the AoC service shall 
include a combination of the following: 

one or more basic services; and/or 

one or more supplementary services; and/or 

one or more network specific services; and/or 

one or more power capability classes (MS classmark); and/or 

the type of radio traffic channel used/ requested; 
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the transparency mode of the basic service employed (transparent/non-transparent); 

the type of call or connection (e.g. MOC/MTC). 
This list may also be extended to include additional network specific parameters. 
Parameters sent to the mobile station during the operation of the AoC service are recorded in the appropriate CDRs. 

5.1.3.2 CAMEL services 

A CAMEL service can be activated for originating, forwarded and terminated calls and originating SMS. Several fields 
describing CAMEL subscription and free format data are recorded to appropriate CDR. For originating and forwarded 
calls two different CAMEL services can be active and part of stored information is different depending on the CAMEL 
call model and which triggers occur. CAMEL fields describing usage level of service, CAMEL modified parameters 
and CAMEL initiated call forwarding include information for one call leg including impacts on all CAMEL services. 

5.1 .3.3 Use of supplementary services 

The recording of supplementary service usage permits the Billing Domain (BD) to specify the supplementary service 
actions (invocation, registration, etc.). 

In addition to specifying the actions to be recorded, the BD may also determine how these events are to be recorded. 
Non-call related events, such as the administration of supplementary services by the subscriber via the MMI of the MS, 
shall result in the production of supplementary service action records. Call related events (e.g. invocation of 
supplementary services) shall be recorded "in-line" in the appropriate CDR and / or in a separate SS-action record 
depending on the configuration specified by the BD. 

Where the use of a supplementary service results in the production of further connections (e.g. call forwarding, 
multi-party service etc.) additional CDRs shall be produced to describe the relevant connections. The use of such 
services is described in more detail both in this clause and in the example scenarios. 

5.1 .3.4 Use of call forwarding 

When one of the call forwarding services is used, the charging function of the MSC server that forwards the call, shall 
produce the MOC record for the forwarded part of the call. 

For further information concerning the recording of call forwarding services see the example scenarios in 
clauses 5.2.1.6 and 5.2.1.7. 

5.1 .3.5 Use of call hold and multi-party services 

The use of the call hold service shall be recorded either in-line in the appropriate CDR or in a separate supplementary 
service "invocation" record as described above. The duration for which the call is held, i.e. is inactive, is not recorded. 

The use of the multi -party service requires a minimum of 3 subscribers and the use of a conference circuit. For the 
purpose of the following description the subscriber invoking the service is referred to as the conference originator ("A") 
and the conference call is regarded as consisting of a number of individual "legs" between the conference originator and 
the other parties ("B", "C", etc.) in the call. 

Normal MOC and MTC CDRs shall be generated for each party and each leg of the call. In addition, if common 
equipment records are enabled, a common equipment record shall be produced for the conference originator in order to 
record the use of a conference bridge and to record the total duration of the conference connection. 

EXAMPLE: Subscriber "C" calls subscriber "A". Subscriber "A" places the call from "C" on hold and makes a 

second call to subscriber "B". Subscriber "A" then invokes the multi-party service in order to 
set-up a conference call with "B" and "C". 

Assuming that the appropriate types of record are enabled, the following CDRs shall be produced: 

- An MOC record for subscriber "C" and the "C"->" A" leg of the call; 

- An MTC record for subscriber "A" and the "C"->"A" leg of the call; 
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- An MOC record for subscriber "A" and the " A"->"B" leg of the call; 

An SS-Action record for the invocation of the call hold service by subscriber "A"; 

- An MTC record for subscriber "B" and the " A"->"B" leg of the call; 

An SS-Action record for the invocation of the multi-party service by subscriber "A"; 

A common equipment record for the use of the conference bridge by subscriber "A". 

Each of the MOC/MTC records for the conference originator ("A") shall include the supplementary service code for the 
multi -party service. 

Any subsequent action affecting only one leg of the connection shall be recorded either in a separate supplementary 
service action record or in-line in the appropriate CDR. Any action affecting the conference as a whole e.g. the 
originator holding the conference shall be recorded either in a separate supplementary service action record or in the 
common equipment usage record. 

For further information concerning the recording of multi-party services see the example scenario in clause 5.2.1.9. 

5.1.3.6 Partial records 

In order to increase the security of the recording process and to simplify post-processing, it may be desirable to generate 
a sequence of CDRs to describe a single connection or transaction. 

In case of connections of extended duration, the loss of a single CDR may result in an unacceptable loss of revenue. If 
the connection is, for example, recorded in a number of consecutive partial records generated at say hourly intervals, 
then the maximum loss of revenue is the equivalent of a one hour continuous connection. 

Most modern billing systems employ some form of cumulative credit-limit checking based on the stream of input 
CDRs. If however, a CDR is only produced at the end of the connection then a subscriber may avoid such credit 
checking by employing a connection for days, weeks or even months without a single CDR being produced. 

All of the records defined in the present document are of variable length and some at least are potentially unlimited in 
size (SET OF, SEQUENCE OF, etc.). However, the storage capacity of the internal records within the network element 
is normally subject to strict size limitations. Under such conditions a partial record may be required in order to 
circumvent internal resource limitations. For example, if an internal MOC record can only support the use of four 
supplementary service invocations then the use of a fifth may result in the generation of a partial record. 

Alternatively, for those manufacturers whose systems are based on fixed length records, partial records may be 
employed instead of the various lists contained within the present document definitions. In such cases a partial record 
will be produced each time one of the key fields alters during the connection. 

Finally, in case of radio link failure and subsequent call re-establishment partial records shall be generated to record the 
duration of the call prior to the radio link failure and the subsequent duration of the call once the call has been re- 
established. 

To summarize, the following events may result in the generation of a partial record: 

expiry of the partial record timer; 

change of basic service during a connection; 

change of location (MCCh-MNCh- LAC or Cell Id. or the Service Access Code, for UMTS) during a connection; 

change of MS classmark during a connection; 

change of AoC Parameters during a call; 

change of Radio Channel Type (full/half rate) during a call; 

radio link failure and subsequent call re-establishment; 

change of HSCSD Parameters (for GSM only) during a call; 

change of CAMEL destination (CAMEL controlled/initiated) during a call; 



£75/ 



3GPP TS 32.250 version 1 0.6.0 Release 1 21 ETSI TS 1 32 250 V1 0.6.0 (201 3-01 ) 

- CAMEL CPH operations on call legs. 

All partial records for the same connection shall contain the same call reference and shall be ordered via a running 
sequence number. The time stamps involved shall apply to the individual partial records rather than the connection as a 
whole i.e. the "end" time stamp (duration) of one record shall, in general, coincide with the "start" time stamp (answer 
time) of the next. Each time a new partial record is created the cause for termination field of the previous record shall 
contain the value "partial record". The cause for termination of the final partial record shall contain the true cause for 
termination of the connection. 

It should be noted that the records produced in case of call re-establishment are not contiguous and that the value of the 
cause for term field in the record that is closed on radio link failure contains the value "partial record call re- 
establishment". 

The partial records generated may repeat each of the non-varying fields contained in the original record. Alternatively, a 
form of reduced partial record may be generated which includes only those fields required to identify the original record 
together with the field(s) that actually change. 

5.1 .3.7 Use of circuit-switched data services 

If data services are employed in conjunction with a Packet-Switched Public Data Network (PSPDN) then an 
MOC/MTC CDR may be produced in the originating/terminating MSC server and a gateway record in the 
gateway/interworking MSC server. If the packet volume is not available within the PLMN then this information may 
also be provided in the form of a CDR from the PSPDN. In such cases the Billing System is responsible for the 
correlation of the various records describing the connection. The definition of such PSPDN CDRs is outside the scope 
of the present document. 

5.1 .3.8 Inter-MSC server handover 

In the case of an inter-MSC server handover the controlling MSC server, as defined by 3GPP TS 23.009 [65], remains 
in control of the connection and shall therefore, produce the CDR. For the avoidance of doubt, it is not necessary to 
produce CDRs in the subsequent MSC server(s). 

5.1.3.9 Call re-establishment 

In case of radio link failure as described in 3GPP TS 24.008 [68], the MS may attempt to re-establish the call using the 
procedures described in 3GPP TS 24.008 [68]. 

For the time period between the detection of the radio link failure by the mobile station and the successful 
re-establishment of the call, the advice of charge function in the MS is suspended as described in 3GPP TS 24.086 [23]. 
In order to minimize the difference in charges between the on-line calculations performed by the MS and the off-line 
processing on the basis of the CDRs, it is necessary to exclude the time taken for the re-establishment phase from the 
chargeable duration stored in the CDRs. 

If the re-establishment attempt fails then an ordinary CDR (MOC/MTC) shall be produced with the cause for 
termination value "stable call abnormal termination". The chargeable duration stored in this record covers the time 
period from "Answer" to the detection of the radio link failure by the MSC server. 

If, the attempt to re-establish the call succeeds then the current CDR shall be closed with the cause for termination value 
"partial record call re-establishment" and a new partial record shall be opened for the re-established call. The chargeable 
duration stored in the original record is once again the time period from "answer" to detection of the radio link failure 
by the MSC server. Both the "seizure" and "answer" times of the subsequent partial record correspond to the time at 
which the new traffic channel is allocated for the re-established call. 

Further radio link failures during the re-established call may result in the generation of additional partial records as 
described above. All of the partial records belonging to the same connection are identified by the same call reference 
and a running sequence number. 

NOTE: As the MS and MSC server may detect the radio link failure at different points in time, it is not possible 
to guarantee that the duration used for the AOC display corresponds to that recorded in the CDRs. The 
purpose of the above procedure is merely to minimize any discrepancies that may occur. 
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5.1 .3.10 Restricted directory numbers 

In addition to the information pertaining to the served mobile subscriber (IMSI, MSISDN, etc.), the CDRs defined in 
the present document also contain the directory numbers of other parties involved in the recorded connections or 
transactions. In order to comply with data protection legislation, it is necessary to distinguish between those numbers 
that may be passed on to third parties and those that needs to be handled confidentially. As a result, each of the number 
fields (e.g. calling/connected number) contains the presentation and screening information defined in both 
TS 24.008 [68] and ISUP signalling. If this information is supported by the network, then even restricted numbers may 
be included in the appropriate records and suppressed off-line by the administration or billing system. If this 
information is not supported then the entire directory number shall be suppressed by the MSC server/VLR. 

5.1.3.11 IM El Observation 

In order to provide the data required by the mobile equipment management activities outlined in the previous clauses, 
the MSC server shall be capable of producing IMEI tickets for each of the following events: 

• usage of a blacklisted IMEI; 

• usage of a greylisted IMEI; 

• usage of an IMEI not found on the white list. 

An observed IMEI ticket is generated whenever greylisted, blacklisted or non-white listed mobile equipment is detected 
during an IMEI check. The purpose of the ticket is to link the mobile equipment under observation with its current user 
(IMSI). The ticket also includes information describing when and where the equipment was used to enable the tracking 
of such equipment. Finally, if the ticket was triggered by a call attempt, a call reference is provided in order to locate the 
corresponding CDR. 

The IMEI tickets are generated by the MSC server performing the IMEI check. 

5.1 .3.1 2 Triggers for LCS-MT-CDR, LCS-MO-CDR and LCS-NI-CDR Charging 
Information Collection 

The LCS CDRs (LCS-MT-CDR, LCS-MO-CDR and LCS-NI-CDR) are used to collect charging information related to 
the LCS features that the PLMN provides in the Packet-Switched domain. 

These records include details such as Record Type, Served IMSI, Sequence Number etc. The LCS records are generated 
based on the following trigger conditions: 

• the LCS-MO-CDR, when the MSC receives the RANAP "Location report" message from the RNC; 

• the LCS-MT-CDR, when the MSC receives the RANAP "Location report" message from the RNC; 

• the LCS-NI-CDR, when the MSC receives the RANAP "Location report" message from the RNC. 

5.1.3.13 BS30 Accounting 

BS30 is an example where the serving network may use a substantially higher radio bandwidth than for a standard voice 
call. While the invocation of this service, including the used radio resources, can be captured in the serving MSC server, 
this is not possible in the GMSC server. However, if the inter-network accounting is done based on GMSC CDRs, this 
information is needed by the GMSC server in order to provide the required CDR information. To that end, the serving 
MSC server can provide this information back to the GMSC server. See clause 5.1.2.2.4 for further details. 

5.1 .3.14 CAMEL Call Party Handling service 

The following appUes to MSCs that are capable of CAMEL Call Party Handling (CPH): 

For calls where CAMEL Call Party Handling (CPH) is involved, one separate record is generated per call segment. The 
CAMEL CPH service may be applied to originating, forwarded and terminated calls as well as SCP initiated calls. 
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For MO, MT and CF call attempts, the fields related to the incoming leg are recorded in the main body. The fields 
related to the outgoing legs of that call segment are recorded in the respective grouped field (CAMEL call leg 
information) per outgoing leg. User Interactions (UI) are recorded in a separate grouped field like outgoing legs. 

Records for gsmSCF initiated call attempts differ to MO, MT and CF records in the following way: no leg information 
shall be recorded in the main body. 

Where the use of CPH result in the creation of further call legs in one call segment, additional grouped fields shall be 
added to the respective CDR. 

Where the use of CPH result in the creation of further call legs in a new call segment, a further CDR shall be generated. 

A CDR is closed when the last leg of the call segment disappeared (moved out, disconnected, etc. ) from the call 
segment. 

When a call leg is moved from one call segment to another, the grouped field for that call leg is closed in the respective 
CDR and a new grouped field is opened in the CDR of the call segment the call leg was moved to. 

When the incoming leg (recorded in the main body), is moved from one call segment to another, the grouped field(s) for 
the outgoing call leg(s) is/are aligned to reflect the new call constellation. 

User interactions (announcements etc.) are recorded in the CDR of the related call segment as a separate grouped field 
similar to call legs. 

The leg specific fields listed below shall be recorded in the grouped field 'CAMEL Call Leg Information' instead of 
using the counterpart in the main body. The counterparts of those fields in the main body are maintained for 
compatibility reasons to earlier releases. 

- CAMEL Destination Number 

Translated Number 

Connected Number 

Roaming Number 

Outgoing TKGP (in 'CAMLEL Call Leg Information' this item is called 
MSC outgoing TKGP) 

- Additional Chg. Info 
Default call handling 2 

- GsmSCF address 2 

Service key 2 

Free format data 2 (in 'CAMEL Call Leg Information' this item is called 
Free format data incoming 2) 

Free format data append indicator 2 (in 'CAMEL Call Leg Information' this item is called 
Free format data append incoming 2) 

Editor's note: both parameters from the second FCI operation should be clarified, also in the CDR table 

Location Routing Number (LRN) 

- LRN Source Indicator 
LRN Query Status Indicator 
JIP Parameter 

JIP Source Indicator 

JIP Query Status Indicator 
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5.1 .3.15 Service Change and Fallback 

Service Change and UDI/RDI Fallback (SCUD IF) provides the possibility of changing the transport bearer capabilities 
for circuit switched multimedia applications using 64 kbit/s UDI refer 3GPP TS 23.172 [209]. 

It allows users to achieve successful call establishment when end to end circuit-switched (CS) multimedia is not 
possible (fallback to speech) or when signalling of the feature is not possible in the network (fallback to preferred 
service). Furthermore, it allows the users to swap between a multimedia service and basic speech during an established 
call. 

SCUDIF functionality encloses two sub-functionalities: 

• Service-Change: when two services (multimedia and speech) are available during the active call, users may request 
a Service-Change to switch between the two services. 

• Fallback: when two services (multimedia and speech and visa versa) are proposed but only one of them is available 
or wanted, only the available service is selected, e.g. fallback from multimedia to speech. 

Editor's note: More details for the charging description are needed. 

5.1.3.16 CS Fallback and SMS over SGs 

CS Fallback is defined in 3GPP TS 23.272 [214] and provides a mechanism to move a UE from EUTRAN PS only 
access to CS to deliver voice service i.e. over GSM or UMTS access. As a result, charging procedures for call handling 
are performed as per GSM and UMTS access. 

Within SMS over SGs also defined in 3GPP TS 23.272 [214], SMS is deHvered in the EUTRAN NAS signalling via the 
SGs interface between the MME and the MSC/VLR. 

5.1 .3.17 Enhanced MSC server for SRVCC support 

The standard MSC behaviour is enhanced for supporting Single Radio Voice Call Continuity (SRVCC) between 
E-UTRAN access and UTRAN/GERAN accesses, between UTRAN (HSPA) access and UTRAN/GERAN accesses, 
for voice calls and emergency calls anchored in the IMS, as defined in TS 23.216 [215]. Charging is provided from the 
MSC server enhanced for SRVCC for successful calls/emergency calls transfer. 

When session transfer procedure from IMS to CS is performed by MSC server enhanced for SRVCC interfacing IMS 
through a SIP interface, according to TS 23.237, this MSC server enhanced for SRVCC behaves as an end-point of the 
IMS domain, and as such, generates an IMS Charging Identifier (ICID) in order to allow correlation. See TS 32.260 
[50] for IMS Charging Identifier (ICID) definition. 

5.1 .3.18 Mobile Terminating Roaming Forwarding call after successful Retrieval of 
Routeing Information (MTRF) 

Mobile Terminating Roaming Forwarding call after successful Retrieval of Routeing Information (MTRF) procedure is 
described in TS 23.018 [216] and provides a mechanism to reroute a terminating call while the called mobile is 
simultaneously moving from an old to a new MSCA'^LR. 

The charging procedures for call handling are performed as for a terminating call in the new MSC/VLR to which the 
call is rerouted. Dedicated charging is provided by the old MSC/VLR from which the call is rerouted as a result of 
MTRF procedure, in order to complete the set of CDRs produced along the path of the call and avoid charging 
duplication. 

When the terminating call is rerouted towards a new MSC/VLR which is located in a different PLMN than the Old 
MSC/VLR, a roaming CDR is produced by the Old MSC/VLR, even when the new MSC/VLR resides in HPLMN. 

The same charging behaviour applies for Roaming Forwarding for CS Fallback defined in 3GPP TS 23.272 [214]. 
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5.2 CS domain offline charging scenarios 
5.2.1 Basic principles 

This clause contains a number of example scenarios illustrating the purpose and practical usage of the various types of 
records defined in the previous clauses. These examples are by no means exhaustive. 

For the purpose of these examples, the following assumptions have been made: 

• that the MSC server and VLR are co-located; 

• that the records are sent to a post-processing system; 

• that the generation of all of the record types described in this clause has been enabled; 

• that the HLR interrogation records are produced in the HLR and not the interrogating MSC server; 

• that supplementary service actions are recorded in separate CDRs. 

The following conventions have been used for the figures contained within this clause: 

1) Network connections and signalling transactions are illustrated by means of solid lines and referenced by number 

e.g. (1); 

2) Operation & Maintenance actions, such as the transfer of CDRs, are represented by means of dotted lines and 
referenced by letter e.g. (A); 

3) The Billing System has been included in some, but not all, of the examples. The only reason for this decision is 
to simplify the resulting figures. The presence of a Billing System is assumed even if not explicitly included. 

The following examples are included: 

1) Mobile to Land (outgoing) call; 

2) Land to Mobile (incoming) call; 

3) Mobile to Mobile call within the same network; 

4) Incoming call to a roaming subscriber; 

5) Incoming call to a PLMN Service Centre; 

6) Call Forwarding Unconditional; 

7) Call Forwarding conditional (on Busy); 

8) Delivery of a Mobile Terminated Short Message; 

9) Call Hold and Multi-party services; 

10) Outgoing call handled by CAMEL; 

11) Incoming call handled by CAMEL without redirection; 

12) Incoming call to a roaming subscriber handled by CAMEL; 

13) Incoming call handled by CAMEL with redirection decided and forwarding leg handled by CAMEL; 

14) Incoming call handled by CAMEL without redirection and forwarded early using GSM SS but controlled by 
CAMEL; 

15) Incoming call handled by CAMEL without redirection and forwarded late using GSM SS but controlled by 
CAMEL; 

16) Early forwarded call controlled by CAMEL; 
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17) Late forwarded call controlled by CAMEL; 

18) Incoming call handled by CAMEL with redirection initiated by CAMEL feature; 

19) Incoming call handled by CAMEL in MSC Server without redirection; 

20) Outgoing call handled by CAMEL Dialled CSI Trigger; 

21) Incoming call handled by CAMEL with redirection decided and forwarding leg handled by CAMEL; 

22) gsmSCF initiated wake-up call handled by CAMEL CPH; 

23) Three party conference handled by CAMEL CPH; 

24) Mobile terminated location request. 
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5.2.1 .1 Mobile to land (outgoing) call 

Figure 5.2.1.1 illustrates a simple outgoing call from a PLMN subscriber "A" to a fixed network subscriber "B" (1). 

The originating MSC server (MSC-A) shall generate an MOC record for subscriber "A". 

The GMSC server shall create an outgoing gateway record for accounting with the fixed network including details of 
the point at which the call left the PLMN i.e. the GMSC server id. and outgoing trunk group. This record also includes 
time stamps to determine both the holding time of the outgoing trunk and the duration of the conversation. 

Even if the MSC server and GMSC server are co-located both records shall be produced. 

The records generated are subsequently transferred to the Billing System of the PLMN (A). 
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Figure 5.2.1 .1 : Mobile to land (outgoing) call 
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5.2.1 .2 Land to mobile (incoming) call 

Figure 5.2.1.2 illustrates a simple incoming call from a fixed network subscriber "A" to a PLMN subscriber "B". 

The incoming call is first routed to a GMSC server (1). The GMSC server shall create an incoming gateway record for 
fixed network accounting purposes to record the point at which the call entered the network together with the time 
stamps required to calculate the holding time of the incoming trunk and the conversation duration. This gateway record 
shall contain the IMSl of the called subscriber. 

The GMSC server interrogates the HLR of the called subscriber in order to determine his current location (2). The HLR 
shall create an HLR interrogation CDR. 

The GMSC server routes the call to the MSC server at which the subscriber is currently registered (3). This terminating 
MSC server (MSC-B) shall create an MTC record for subscriber "B". 

Even if the MSC server and GMSC server are co-located both the MTC and gateway records shall be produced. 

The records generated are subsequently transferred to the Billing System of the PLMN (A). 
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Figure 5.2.1.2: Land to mobile (incoming) call 
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5.2.1.3 



Mobile to mobile call within the same network 



Figure 5.2.1.3 illustrates a simple mobile to mobile call from subscriber "A" to subscriber "B" both within the same 
PLMN. 

The originating MSC server (MSC-A) shall produce an MOC record for the call to subscriber "B". 

Having received a set-up request from subscriber "A" (1), MSC-A interrogates the HLR of the called subscriber in order 
to determine his current location (2). The HLR shall create an HLR interrogation CDR. 

MSC-A routes the call to the MSC server at which subscriber is currently registered (3). This terminating MSC server 
(MSC-B) shall create an MTC record for subscriber "B". If MSC-A and MSC-B ai-e co-located, then both the MOC and 
the MTC records shall be produced in the same MSC for this call. 

The records generated are subsequently transferred to the Billing System of the PLMN. 
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Figure 5.2.1.3: Mobile to mobile call 
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5.2.1.4 



Incoming call to a roaming subscriber 



Figure 5.2.1.4 illustrates an incoming call from a fixed network subscriber "A" to a PLMN subscriber "B" who is 
currently roaming in another PLMN. 

The call is first routed to a GMSC server (1) and the GMSC server shall create an incoming gateway record for 
accounting purposes as described in clause 5.2.1.2. The GMSC server interrogates the HLR of the called subscriber in 
order to determine his current location (2). The HLR shall create an Interrogation event record. 

The GMSC server routes the call to the VPLMN in which subscriber "B" is currently located (3). The GMSC server 
shall create an outgoing gateway record for accounting purposes. The GMSC server shall also create a roaming record. 
This record includes the IMSl of the "B" subscriber and may be used as a cross-check for the TAP information received 
from the VPLMN. 

The call is then routed by the VPLMN to the MSC server at which the subscriber is currently located (4). The GMSC 
server of the VPLMN shall produce an incoming gateway record and the terminating MSC server shall create an MTC 
record for the call to "B". 

The records generated are subsequently transferred to the Billing System of the appropriate PLMN (A). The MTC 
record generated by the terminating MSC server shall be employed to create the appropriate MTC TAP record. The 
TAP records shall be included in a TAP file and transmitted to the HPLMN (B). 
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Figure 5.2.1.4: Incoming call to a roaming subscriber 
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5.2.1.5 



Incoming call to a PLMN service centre 



Figure 5.2.1.5 illustrates an incoming call from a fixed network subscriber "A" to a Service Centre directly connected to 
an MSC server within a PLMN network. Examples for services provided by such a Service Centre include Voice Mail 
services, Operator services, etc. 

The call is routed to a GMSC server within the PLMN (1). The GMSC server analyses the dialled digits and routes the 
call directly to the MSC server to which the Service Centre is connected (2). 

As HLR interrogation is not required, there will be no HLR Interrogation record. The GMSC server shall however, 
create an incoming gateway record based on the point at which the call entered the network and the destination (Service 
Centre) of the call. 

The MSC server then connects the calling subscriber to the service centre. As no mobile subscriber is involved, the 
MSC server will not create an MTC record, however, the MSC server shall create a transit record describing the 
destination of the call. 

The records generated are subsequently transferred to the Billing System of the PLMN (A). 

It should be noted that without the transit record, the MSC server would not generate a record for this connection. 
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Figure 5.2.1.5: Incoming call to a PLMN service centre 
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5.2.1.6 



Call forwarding unconditional 



Figure 5.2.1.6 illustrates an incoming call from a fixed network subscriber "A" to a mobile subscriber "B" who has 
registered and activated Call Forwarding Unconditional (CFU) for the appropriate service. The call is subsequently 
forwarded to a second fixed network subscriber "C". 

For simplicity the registration and activation of CFU have not been included in the diagram. These actions shall of 
course be recorded in the appropriate supplementary service records. 

The incoming call is routed to a GMSC server (1). This part of the connection is identical to the scenario outlined in 
clause 5.2.1.2. 

The GMSC server interrogates the HLR of the called subscriber in order to determine his current location (2). The HLR 
shall create an HLR interrogation CDR. The HLR informs the GMSC server that "B" has activated CFU to subscriber 
"C". 

The GMSC server forwards the call to the fixed network subscriber "C" (3). The GMSC server shall create an MTC 
record for the "B" subscriber for the call from "A" and an MOC (call forwarding) record for the "B" subscriber for the 
call to "C". Both records shall contain the supplementary service employed (CFU). The GMSC server shall also 
produce an outgoing gateway record as described in clause 5.2.1.1. 

The records generated are subsequently transferred to the Billing System of the HPLMN (A). 
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Figure 5.2.1.6: Call forwarding unconditional 
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5.2.1.7 



Call forwarding conditional (on busy) 



Figure 5.2.1.7 illustrates a mobile originated call from subscriber "A" to a second mobile subscriber "B" who has 
registered and activated Call Forwarding on Busy (CFB) for the appropriate service. The call is subsequently forwarded 
to a third mobile subscriber "C". In this example, all three subscribers are currently located within the same (the home) 
network. 

For simplicity the registration and activation of CFB have not been included in the diagram. 

Having received a set-up request from subscriber "A" (1), the originating MSC server (MSC-A) interrogates the HLR of 
subscriber "B" in order to determine his current location (la). The call is then routed to MSC-B (2). 

MSC-A shall create an MOC record for subscriber "A" containing details of the call to "B". The HLR shall produce an 
HLR interrogation record. 

On determining that subscriber "B" is busy and that CFB is active, the forwarding MSC server/VLR (MSC-B) 
interrogates the HLR of subscriber "C" to determine his current location (2a) and forwards the call accordingly (3). 

MSC-B shall produce an MTC record for the "B" subscriber for the call from "A" and an MOC record for the "B" 
subscriber for the call to "C". Both records shall include the supplementary service employed (CFB). The HLR shall 
produce an Interrogation record. 

The terminating MSC server (MSC-C) shall create a normal MTC record for subscriber "C". 

The records generated are subsequently transferred to the Billing System of the PLMN. 
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Figure 5.2.1.7: Call forwarding conditional (busy) 
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5.2.1 .8 Delivery of a mobile terminated short message 

Figure 5.2.1.8 illustrates the delivery of a short message to a mobile subscriber. 

The short message service centre delivers the message to a GMSC server or gateway function (1). The GMSC server 
shall create an SMS gateway MT record. 

The GMSC server then interrogates the HLR of the subscriber to determine his current location (2). The HLR shall 
create an HLR interrogation record. 

The message is subsequently transmitted to the MSC server serving the mobile subscriber and finally to the mobile 
station of that subscriber (3). The MSC server shall create an SMS MT record. 

The records generated are subsequently transferred to the post-processing system of the HPLMN (A). 
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Figure 5.2.1.8: Delivery of a short message to a mobile subscriber 
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5.2.1 .9 Call hold and multi-party service 

Figure 5.2.1.9 illustrates the use of the call hold and multi-party services. 

A mobile subscriber ("A") sets up an outgoing call (1) to an ISDN subscriber ("B"). This call is recorded as outlined in 
clause 5.2.1.1. 

Subscriber "A" then invokes the call hold service. MSC-A shall produce a supplementary service action record for the 
invocation. 

Subscriber "A" then sets up a side-call (2) to a second mobile subscriber ("C") within the same network. This call is 
recorded as outlined in clause 5.2.1.3. 

Subscriber "A" subsequently invokes the multi-party service in order to set up a three-party conference with "B" and 
"C". MSC-A shall produce a common equipment record for the use of a conference circuit by subscriber "A". This 
record shall record the duration of the whole conference irrespective of the number of parties subsequently added to, or 
removed from the conference connection. 

Note that the MOC records produced by MSC-A for both the A -> B and A -> C legs of the conference shall contain the 
supplementary service code for multi-party. 
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Figure 5.2.1.9: Call hold and multi-party service 
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5.2.1 .10 Outgoing call handled by CAMEL 

Figure 5.2.1.10 illustrates an outgoing CAMEL call from a mobile CAMEL subscriber "A" to a fixed network 
subscriber "B" (1). 

The "A" subscriber has an active O-CSI (stored in the VLR). Therefore MSC server-A requests instructions from the 
gsmSSF which passes the CAMEL service key to the gsmSCF to indicate which service logic it should apply (2). 

The gsmSCF may interrogate the HLR for subscriber information. As a network option, the operator may refuse to 
provide the requested information. 

When gsmSCF processing is complete the call control is returned to MSC-A. 

MSC server-A generates an MOC record for the "A" subscriber. This record may be linked to an optional SCF-record. 
The record includes O-CSl data. 

The GMSC server routes the call to the "B" subscriber (3). The GMSC server shall create an outgoing gateway record 
as described in clause 5.2.1.1. 

The generated records are subsequently transferred to the Billing System of the HPLMN (A). 

The following records are generated in HPLMN in this call scenario. 

Table 5.2.1.10: Records Generated for an Outgoing Call Handled by CAMEL 



GMSC server 


MSC server 


HLR 


Outgoing gateway record 


MOC record 


- 
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Figure 5.2.1.10: Outgoing call handled by CAMEL 
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5.2.1 .1 1 Incoming call handled by CAMEL without redirection 

Figure 5.2.1.11 illustrates an incoming call from a fixed network subscriber "A" to a mobile CAMEL subscriber "B". 

The incoming call is first routed to the GMSC server (1). The GMSC server shall create an incoming gateway record for 
fixed network accounting purposes. 

The GMSC server interrogates the HLR of the called subscriber in order to fetch the T-CSl (2). The HLR shall create an 
HLR interrogation record. 

The "B" subscriber has an active T-CSI. Therefore the GMSC server requests instructions from the gsmSSF which 
passes the CAMEL service key to a gsmSCF to indicate which service logic it should apply (3). 

The gsmSCF may interrogate the HLR for subscriber information. As a network option, the operator may refuse to 
provide the requested information. 

When gsmSCF processing is complete the call control is returned to the GMSC server. The GMSC server shall generate 
a terminating CAMEL record which contains T-CSl data. 

The GMSC server interrogates the HLR in order to determine his current location (4). The HLR shall create an HLR 
interrogation record. 

The call is routed to MSC-B (5). An MTC record shall be generated. 

For avoidance of doubt, even if the MSC server and GMSC server are co-located both the MTC and gateway records 
shall be produced. 

The generated records are subsequently transferred to the Billing System of the HPLMN (A). 

The following records are generated in HPLMN in this call scenario. 

Table 5.2.1.11 : Records Generated for an Incoming Call Handled by CAMEL without Re-direction 



GMSC server 


MSC server 


HLR 


Incoming gateway record 


MTC record 


HLR interrogation record 


Terminating CAIVIEL record 
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Figure 5.2.1 .1 1 : Incoming call handled by CAMEL without redirection 
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5.2.1 .12 Incoming call to a roaming subscriber handled by CAMEL 

Figures. 12 illustrates an incoming call from a fixed network subscriber "A" to a mobile CAMEL subscriber "B" who is 
currently roaming in another PLMN. 

The call is first routed to a GMSC server (1) and the GMSC server shall create an incoming gateway record for fixed 
network accounting purposes. 

The GMSC server interrogates the HLR of the called subscriber in order to fetch the T-CSI (2). The HLR shall create an 
HLR interrogation record. 

The "B" subscriber has an active T-CSl. Therefore the GMSC server requests instructions from the gsmSSF which 
passes the CAMEL service key to a gsmSCF to indicate which service logic it should apply (3). 

The gsmSCF may interrogate the HLR for subscriber information. As a network option, the operator may refuse to 
provide the requested information. 

When gsmSCF processing is complete the call control is returned to the GMSC server . The GMSC server shall 
generate a terminating CAMEL record which contains T-CSl data. 

The GMSC server interrogates the HLR in order to determine his current location (4). The HLR shall create an HLR 
interrogation record. 

The GMSC server routes the call to the VPLMN in which subscriber "B" is currently located (5). The GMSC server 
shall create an outgoing gateway record for accounting purposes. The GMSC server shall also create a roaming record. 
This record includes the IMSl of the "B" subscriber and may be used as a cross-check for the TAP information received 
from the VPLMN. 

The call is then routed by the VPLMN to the MSC server at which the subscriber is currently located (6). The GMSC 
server of the VPLMN shall produce an incoming gateway record and the terminating MSC server shall create an MTC 
record for the call to "B". 

The records generated are subsequently transferred to the Billing System of the appropriate PLMN (A). The MTC 
record generated by the terminating MSC server shall be employed to create the appropriate MTC TAP record. The 
TAP records shall be included in a TAP file and transmitted to the HPLMN (B). 

The following records are generated in HPLMN in this call scenario. 

Table 5.2.1.12.1: Records Generated in the HPLMN for an 
Incoming Call to a Roaming Subscriber Handled by CAMEL 



GMSC server 


MSC server 


HLR 


Incoming gateway record 


- 


HLR interrogation record 


Terminating CAIVIEL record 






Roaming record 






Outgoing gateway record 







The following records are generated in VPLMN in this call scenario. 



Table 5.2.1.12.2: Records Generated in the VPLMN for an 
Incoming Call to a Roaming Subscriber Handled by CAMEL 



GMSC server 


MSC server 


HLR 


Incoming gateway record 


MTC record 


- 
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Figure 5.2.1.12: Incoming call to a roaming subscriber handled by CAMEL 
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5.2.1 .13 Incoming call handled by CAMEL with redirection decided and forwarding leg 
handled by CAMEL 

Figure 5.2.1.13 illustrates an incoming call from a fixed network subscriber "A" to a mobile CAMEL subscriber "B". 
The call is subsequently forwarded to a second fixed network subscriber "C" by CAMEL initiated Call Forwarding. 

The incoming call is routed to the GMSC server (1). The GMSC server shall create an incoming gateway record for 
fixed network accounting purposes. 

The GMSC server interrogates the HLR of the called subscriber in order to fetch the T-CSl and O-CSl (2). 

The "B" subscriber has an active T-CSl. Therefore the GMSC server requests instructions from the gsmSSF which 
passes the CAMEL service key to a gsmSCF to indicate which service logic it should apply (3). 

The gsmSCF may interrogate the HLR for subscriber information. As a network option, the operator may refuse to 
provide the requested information. 

The gsmSCF modifies the Called Party number and sets the CAP parameter 'Apply O-CSl'. When gsmSCF processing 
is complete the call control is returned to the GMSC server. The GMSC server shall generate a terminating CAMEL 
record which contains T-CSl data. 

The "B" subscriber has an active O-CSl. Therefore the GMSC server requests instructions from the gsmSSF which 
passes the CAMEL service key to a gsmSCF to indicate which service logic it should apply (4). 

The gsmSCF may interrogate the HLR for subscriber information. As a network option, the operator may refuse to 
provide the requested information. 

When gsmSCF processing is complete the call control is returned to the GMSC server. 

The GMSC server redirects the call to the fixed network subscriber "C" (5). The GMSC server shall generate an MTC 
record for the "B" subscriber for the call from "A" and an MOC (call forwarding) record for the "B" subscriber for the 
call to "C". The MOC record includes O-CSl data and the parameter 'CAMEL initiated CF indicator'. The GMSC 
server shall also produce an outgoing gateway record as described in clause 5.2.1.1. 

The generated records are subsequently transferred to the Billing System of the HPLMN (A). 

The following records are generated in HPLMN in this call scenario. 

Table 5.2.1.13: Records Generated in the Incoming Call with 
Redirection Decided and Forwarded Leg Handled by CAMEL 



GMSC server 


MSC server 


HLR 


Incoming gateway record 


- 


HLR interrogation record 


Terminating CAIVIEL record 






IVITC record 






MOC (CF) record 






Outgoing gateway record 
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Figure 5.2.1.13: Incoming call handled by CAMEL with redirection decided 
and forwarding leg handled by CAMEL 
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5.2.1 .14 Incoming call handled by CAMEL without redirection and forwarded early 
using GSM SS but controlled by CAMEL 

Figure 5.2.1.14 illustrates an incoming call from a fixed network subscriber "A" to a mobile CAMEL subscriber "B". 
The call is subsequently forwarded to a second fixed network subscriber "C" by GSM SS Call Forwarding 
Unconditional (CFU) but controlled by CAMEL. 

For simplicity the activation and registration of CFU have not been included in the diagram. These actions shall of 
course be registered in the appropriate supplementary service records. 

The incoming call is routed to the GMSC server (1). The GMSC server shall create an incoming gateway record for 
fixed network accounting purposes. 

The GMSC server interrogates the HLR of the called subscriber in order to fetch the T-CSI and O-CSI (2). The HLR 
shall create an HLR interrogation record. The HLR informs the GMSC server that "B" has activated CFU. 

The "B" subscriber has an active T-CSl. Therefore the GMSC server requests instructions from the gsmSSF which 
passes the CAMEL service key to a gsmSCF to indicate which service logic it should apply (3). 

The gsmSCF may interrogate the HLR for subscriber information. As a network option, the operator may refuse to 
provide the requested information. 

When gsmSCF processing is complete the call control is returned to the GMSC server. The GMSC server shall generate 
a terminating CAMEL interrogation record which contains T-CSl data. 

The "B" subscriber has an active O-CSl. Because the "B" subscriber has activated CFU he acts as the originating party 
for the forwarded leg. Therefore the GMSC server requests instructions from the gsmSSF which passes the CAMEL 
service key to a gsmSCF to indicate which service logic it should apply (5). 

The gsmSCF may interrogate the HLR for subscriber information. As a network option, the operator may refuse to 
provide the requested information. 

When gsmSCF processing is complete the call control is returned to the GMSC server. 

The GMSC server redirects the call to the fixed network subscriber "C" (6). The GMSC server shall generate an MTC 
record for the "B" subscriber for the call from "A" and an MOC (call forwarding) record for the "B" subscriber for the 
call to "C". The MOC record includes O-CSl data. The GMSC server shall also produce an outgoing gateway record as 
described in clause 5.2.1.1. 

If the B-subscriber do not have an active O-CSl the call is forwarded to the "C" subscriber after the first gsmSCF 
invocation, and the GMSC server shall generate an MOC (call forwarding) record for the "B" subscriber for the call to 
"C". 

The generated records are subsequently transferred to the Billing System of the HPLMN (A). 

The following records are generated in HPLMN in this call scenario. 

Table 5.2.1.14: Records Generated in the Incoming call handled by CAMEL without redirection 
and forwarded early using GSM SS but controlled by CAMEL 



GMSC server 


MSC server 


HLR 


Incoming gateway record 


- 


HLR interrogation record 


Terminating CAIVIEL record 






IVITC record 






MOC (CF) record 






Outgoing gateway record 
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Figure 5.2.1.14: Incoming call handled by CAMEL without redirection 
and forwarded early using GSM SS but controlled by CAMEL 
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5.2.1 .15 Incoming call handled by CAMEL without redirection and forwarded late 
using GSM SS but controlled by CAMEL 

Figure 5.2.1.15 illustrates an incoming call from a fixed network subscriber "A" to a mobile CAMEL subscriber "B" 
who has registered and activated Call Forwarding on No Reply (CFNRY) for the appropriate service. The call is 
subsequently forwarded to a second fixed network subscriber "C". 

For simplicity the registration and activation of CFNRY have not been included in this diagram. These actions shall be 
recorded in the appropriate supplementary service records. 

The incoming call is routed to the GMSC server (1). The GMSC server shall create an incoming gateway record for 
fixed network accounting purposes. 

The GMSC server interrogates the HLR of the called subscriber in order to fetch the T-CSI and O-CSI (2). The HLR 
shall create an HLR interrogation record. 

The "B" subscriber has an active T-CSl. Therefore the GMSC server requests instructions from the gsmSSF which 
passes the CAMEL service key to the gsmSCF to indicate which service logic it should apply (3). 

The gsmSCF may interrogate the HLR for subscriber information. As a network option, the operator may refuse to 
provide the requested information. 

When gsmSCF processing is complete the call control is returned to the GMSC server. The GMSC server shall generate 
a terminating CAMEL interrogation record which contains T-CSl data. 

The GMSC server interrogates the HLR in order to determine his current location (4). The HLR shall create an HLR 
interrogation record. 

The call is routed to MSC-B (5). The "B" subscriber do not answer the call. MSC-B shall produce an MTC record for 
the "B" subscriber for the call from "A". 

The "B" subscriber has an active O-CSl. Because the "B" subscriber has activated CFNRY he acts as the originating 
party for the forwarded leg. Therefore MSC-B requests instructions from the gsmSSF which passes the CAMEL service 
key to the gsmSCF to indicate which service logic it should apply (6). 

The gsmSCF may interrogate the HLR for subscriber information. As a network option, the operator may refuse to 
provide the requested information. 

When gsmSCF processing is complete the call control is returned to MSC-B. 

MSC-B forwards the call via the GMSC server to the "C" subscriber (7). MSC-B shall produce an MOC (call 
forwarding) for the "B" subscriber for the call to "C". The record includes O-CSl data. The GMSC server shall also 
produce an outgoing gateway record as described in clause 5.2.1.1. 

If the B-subscriber do not have an active O-CSl the call is forwarded to the "C" subscriber after detecting the call 
forwarding condition, and the GMSC server shall generate an MOC (call forwarding) record for the "B" subscriber for 
the call to "C". 

The generated records are subsequently transferred to the Billing System of the HPLMN (A). 

The following records are generated in HPLMN in this call scenario. 

Table 5.2.1.15: Records Generated in the Incoming call handled by CAMEL without redirection 
and forwarded late using GSM SS but controlled by CAMEL 



GMSC server 


MSC server 


HLR 


Incoming gateway record 


MTC record 


- 


Terminating CAIVIEL record 


MOC (CF) record 




Outgoing gateway record 
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Figure 5.2.1.15: Incoming call handled by CAMEL without redirection 
and forwarded late using GSM SS but controlled by CAMEL 



ETSI 



3GPP TS 32.250 version 10.6.0 Release 10 



48 



ETSI TS 132 250 VI 0.6.0 (2013-01) 



5.2.1.16 Early forwarded call controlled by CAMEL 

Figure 5.2.1.16 illustrates an incoming call from a fixed network subscriber "A" to a mobile CAMEL subscriber "B". 
The call is subsequently forwarded to a second fixed network subscriber "C" by GSM SS Call Forwarding 
Unconditional (CFU) but controlled by CAMEL. 

For simplicity the activation and registration of CFU have not been included in the diagram. These actions shall of 
course be registered in the appropriate supplementary service records. 

The incoming call is routed to the GMSC server (1). The GMSC server shall create an incoming gateway record for 
fixed network accounting purposes. 

The GMSC server interrogates the HLR of the called subscriber in order to fetch the O-CSl (2). The HLR shall create 
an HLR interrogation record. The HLR informs the GMSC server that "B" has activated CFU. 

The "B" subscriber has an active O-CSl. Because the "B" subscriber has activated CFU he acts as the originating party 
for the forwarded leg. Therefore the GMSC server requests instructions from the gsmSSF which passes the CAMEL 
service key to a gsmSCF to indicate which service logic it should apply (3). 

The gsmSCF may interrogate the HLR for subscriber information. As a network option, the operator may refuse to 
provide the requested information. 

When gsmSCF processing is complete the call control is returned to the GMSC server. 

The GMSC server redirects the call to the fixed network subscriber "C" (5). The GMSC server shall generate an MTC 
record for the "B" subscriber for the call from "A" and an MOC (call forwarding) record for the "B" subscriber for the 
call to "C". The MOC record includes O-CSl data. The GMSC server shall also produce an outgoing gateway record as 
described in clause 5.2.1.1. 

The generated records are subsequently transferred to the Billing System of the HPLMN (A). 

The following records are generated in HPLMN in this call scenario. 

Table 5.2.1.16: Records Generated in the Early forwarded call controlled by CAMEL 



GMSC server 


MSC server 


HLR 


Incoming gateway record 


- 


HLR interrogation record 


MTC record 






MOC (CF) record 






Outgoing gateway record 
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Figure 5.2.1.16: Early forwarded call controlled by CAMEL 
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5.2.1 .17 Late forwarded call controlled by CAMEL 

Figure 5.2.1.17 illustrates an incoming call from a fixed network subscriber "A" to a mobile CAMEL subscriber "B" 
who has registered and activated Call Forwarding on No Reply (CFNRY) for the appropriate service. The call is 
subsequently forwarded to a second fixed network subscriber "C". 

For simplicity the registration and activation of CFNRY have not been included in this diagram. These actions shall be 
recorded in the appropriate supplementary service records. 

The incoming call is routed to the GMSC server (1). The GMSC server shall create an incoming gateway record for 
fixed network accounting purposes. 

The GMSC server interrogates the HLR of the called subscriber in order to determine the current location (2). The HLR 
shall create an HLR interrogation record. 

The call is routed to MSC-B (3). The "B" subscriber do not answer the call. MSC-B shall produce an MTC record for 
the "B" subscriber for the call from "A". 

The "B" subscriber has an active O-CSl. Because the "B" subscriber has activated CFNRY he acts as the originating 
party for the forwarded leg. Therefore MSC-B requests instructions from the gsmSSF which passes the CAMEL service 
key to gsmSCF-B to indicate which service logic it should apply (4). 

The gsmSCF may interrogate the HLR for subscriber information. As a network option, the operator may refuse to 
provide the requested information. 

When gsmSCF processing is complete the call control is returned to MSC-B. 

MSC-B forwards the call via the GMSC server to the "C" subscriber (5). MSC-B shall produce an MOC (call 
forwarding) for the "B" subscriber for the call to "C". The record includes O-CSl data. The GMSC server shall also 
produce an outgoing gateway record as described in clause 5.2.1.1. 

The generated records are subsequently transferred to the Billing System of the HPLMN (A). 

The following records are generated in HPLMN in this call scenario. 

Table 5.2.1.17: Records Generated in the Late forwarded call controlled by CAMEL 



GMSC server 


MSC server 


HLR 


Incoming gateway record 


MTC record 


HLR interrogation record 


Outgoing gateway record 


MOC (CF) record 
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Figure 5.2.1.17: Late forwarded call controlled by CAMEL 
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5.2.1 .18 Incoming call handled by CAMEL with redirection initiated by CAMEL feature 

Figure 5.2.1.18 illustrates an incoming call from a fixed network subscriber "A" to a mobile CAMEL subscriber "B". 
The call is subsequently redirected to a second fixed network subscriber "C" by CAMEL initiated redirection. 

The incoming call is routed to the GMSC server (1). The GMSC server shall create an incoming gateway record for 
fixed network accounting purposes. 

The GMSC server interrogates the HLR of the called subscriber in order to fetch the T-CSl (2) and the O-CSI (2). The 
HLR shall create an HLR interrogation record. 

Since subscriber "B" has an active T-CSl and the trigger criteria are met the GMSC server requests instructions from 
the gsmSSF which passes the CAMEL service key to a gsmSCF to indicate which service logic it should apply (3). A 
terminating CAMEL interrogation record is generated in the GMSC server for invoking the terminating CAMEL call 
handling. 

The gsmSCF may interrogate the HLR for subscriber information. As a network option, the operator may refuse to 
provide the requested information. 

The gsmSCF returns a modified destination routing address to the GMSC server (without the option "apply O-CSI"). 
Therefore for the redirection leg (B-C) the CAMEL feature is not invoked. 

The GMSC server redirects the call to the fixed network subscriber "C" (4). For fixed network accounting purposes the 
GMSC server shall generate an outgoing gateway record as described in clause 5.2.1.1. 

The generated records are subsequently transferred to the Billing System of the HPLMN (A). 

The following records are generated in HPLMN in this call scenario. 

Table 5.2.1.18: Records Generated in the Incoming call handled by CAMEL 
with redirection initiated by CAMEL feature 



GMSC server 


MSC server 


HLR 


Incoming gateway record 




HLR interrogation record 


Terminating CAIVIEL 
interrogation record 






Outgoing gateway record 
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Figure 5.2.1.18: Incoming call handled by CAMEL with redirection initiated and by CAMEL feature 
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5.2.1 .19 CAMEL Scenario for Visiting Terminator Trigger Calls 

Figure 5.2.1.19 illustrates an incoming call from a fixed network subscriber "A" to a mobile CAMEL subscriber "B". 

The incoming call is first routed to the GMSC (1). The GMSC shall create an incoming gateway record for fixed 
network accounting purposes. 

The GMSC interrogates the HLR (2) of the called subscriber. The HLR shall create an HLR interrogation record. The 
call is routed to MSC-B(3). An MTC record shall be generated in MSC-B. 

The "B" subscriber has an active VT-CSl (stored in the VLR). For avoidance of doubt in this scenario, the "B" 
subscriber does not have an active T-CSl in the HLR. Therefore MSC-B requests instructions from the gsmSSF which 
passes the CAMEL service key to the gsmSCF to indicate which service logic it should apply (4). 

The gsmSCF may interrogate the HLR for subscriber information. As a network option, the operator may refuse to 
provide the requested information. 

When gsmSCF processing is complete the call control is returned to the MSC-B. The MSC-B shall generate a 
terminating CAMEL (TCR) record which contains VT-CSl data. 

The MSC-B routes the call to the "B" subscriber (5). 

For avoidance of doubt, even if the MSC and GMSC are co-located both the MTC/TCR and gateway records shall be 
produced. 

The generated records are subsequently transferred to the OS (A) either as event reports following the release of the 
connection or when collected by the OS. 

The following records are generated in HPLMN in this call scenario. 

Table 5.2.1.19: Records Generated for Visiting Terminating Trigger Calls 



GMSC 


MSC-B 


HLR 


Incoming gateway record 


MTC record 


HLR interrogation record 




Terminating CAMEL record 
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Figure 5.2.1.19: Incoming call handled by CAMEL in MSC Server without redirection 
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5.2.1 .20 Outgoing call handled by CAMEL with Dialled CSI Trigger 

Figure 5.2.1.20 illustrates an outgoing CAMEL call from a mobile CAMEL subscriber "A" to a fixed network 
subscriber "B" (1). 

The "A" subscriber has an active D-CSI (stored in the VLR and modified Called Party number matches D-CSI). 
Therefore MSC server-A requests instructions from the gsmSSF which passes the CAMEL service key to the gsmSCF 
to indicate which service logic it should apply (2). 

The gsmSCF may interrogate the HLR for subscriber information. As a network option, the operator may refuse to 
provide the requested information. 

When gsmSCF processing is complete the call control is returned to MSC-A. 

MSC server-A generates an MOC record for the "A" subscriber which contains D-CSl data. This record may be linked 
to an optional SCF-record. 

The GMSC server routes the call to the "B" subscriber (3). The GMSC server shall create an outgoing gateway record 
as described in clause 5.2.1.1. 

The generated records are subsequently transferred to the post-processing system (A) either as event reports following 
the release of the connection or when collected by the post-processing system. 

The following records are generated in HPLMN in this call scenario. 

Table 5.2.1.20: Records Generated for an Outgoing Call Handled by CAMEL 



GMSC server 


MSC server 


HLR 


Outgoing gateway record 


MOC record 


- 
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Figure 5.2.1.20: Outgoing call handled by CAMEL with Dialled CSI Trigger 
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5.2.1 .21 Incoming call handled by CAMEL with redirection decided and forwarding leg 

handled by CAMEL with Dialled CSI Trigger 

Figure 5.2.1.21 illustrates an incoming call from a fixed network subscriber "A" to a mobile CAMEL subscriber "B". 
The call is subsequently forwarded to a second fixed network subscriber "C" by CAMEL initiated Call Forwarding. 

The incoming call is routed to the GMSC server (1). The GMSC server shall create an incoming gateway record for 
fixed network accounting purposes. 

The GMSC server interrogates the HLR of the called subscriber in order to fetch the T-CSl, O-CSl and D-CSl (2). 

The "B" subscriber has an active T-CSl. Therefore the GMSC server requests instructions from the gsmSSF which 
passes the CAMEL service key to a gsmSCF to indicate which service logic it should apply (3). 

The gsmSCF may interrogate the HLR for subscriber information. As a network option, the operator may refuse to 
provide the requested information. 

The gsmSCF modifies the Called Party number and sets the CAP parameter 'Apply O-CSl'. When gsmSCF processing 
is complete the call control is returned to the GMSC server. The GMSC server shall generate a terminating CAMEL 
interrogation record which contains T-CSl data. 

The "B" subscriber has an active O-CSl. Therefore the GMSC server requests instructions from the gsmSSF which 
passes the CAMEL service key to a gsmSCF to indicate which service logic it should apply (4). 

The gsmSCF may interrogate the HLR for subscriber information. As a network option, the operator may refuse to 
provide the requested information. 

The gsmSCF modifies the Called Party number. When gsmSCF processing is complete the call control is returned to the 
GMSC server. 

The "B" subscriber has an active D-CSI (modified Called Party number matches D-CSI). Therefore the GMSC server 
requests instructions from the gsmSSF which passes the CAMEL service key to a gsmSCF to indicate which service 
logic it should apply (5). 

The gsmSCF may interrogate the HLR for subscriber information. As a network option, the operator may refuse to 
provide the requested information. When gsmSCF processing is complete the call control is returned to the GMSC 
server. 

The GMSC server redirects the call to the fixed network subscriber "C" (6). The GMSC server shall generate an MTC 
record for the "B" subscriber for the call from "A" and an MOC (call forwarding) record for the "B" subscriber for the 
call to "C". The MOC record includes O-CSl data, the parameter 'CAMEL initiated CF indicator' and D-CSl data. The 
GMSC server shall also produce an outgoing gateway record as described in clause 5.2.1.1. 

The generated records are subsequently transferred to the post-processing system (A) either as event reports following 
the release of the connection or when collected by the post-processing system. 

The following records are generated in HPLMN in this call scenario. 

Table 5.2.1.21 : Records Generated in the Incoming Call with 
Redirection Decided and Forwarded Leg Handled by CAMEL 



GMSC server 


MSC server 


HLR 


Incoming gateway record 


- 


HLR interrogation record 


Terminating CAIVIEL record 






IVITC record 






MOC (CF) record 






Outgoing gateway record 
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Figure 5.2.1 .21 : Incoming call handled by CAMEL with redirection decided 
and forwarding leg handled by CAMEL with Dialled CSI Trigger 
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5.2.1 .22 Mobile terminated location request 

Figure 5.2.1.22 illustrates general network positioning for LCS clients external to the PLMN. 

An external LCS client requests the current location of a target UE from a GMLC (1). In this release the GMLC shall 
not create any LCS record. 

The GMLC server then interrogates the HLR of the target UE to be located to determine his current location (2). The 
HLR shall create an HLR interrogation record. 

The GMLC sends the location service request to the MSC indicated by the HLR. The MSC sends a Location Request 
message to RAN that initiates the positioning procedure (3). The MSC shall create an LCS-MT record. 

The records generated are subsequently transferred to the Billing System of the PLMN (A). 
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Figure 5.2.1.22: Mobile terminated location request 
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5.2.1 .23 gsmSCF initiated wake-up call handled by CAMEL CPH 

Figure 5.2.1.23 illustrates a wake-up call initiated by gsmSCF to a mobile CAMEL subscriber "A". 

gsmSCF interrogates the HLR in order to determine the current location of subscriber "A" (1). The HLR provides the 
'Roaming Number'. The HLR shall create an interrogation record. 

gsmSCF initiates set-up of an outgoing leg towards mobile CAMEL subscriber "A" (2). The MSC shall create an 
adapted version of MOC and MTC record for that call leg. 

The user interaction (Ul), in this scenario an announcement from the Specialised Resource Function (SRF), is 
connected to mobile CAMEL subscriber "A" (3). The MSC shall update the MOC record to reflect the Ul. 

The following records are generated in HPLMN in this call scenario. 

Table 5.2.1.23: Records Generated for an Wake-up Call Handled by CAMEL CPH 



MSC 


HLR 


MOC record 


HLR interrogation record 


MTC record 






Figure 5.2.1.23: Wake-up call handled by CAMEL CPH 
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5.2.1 .24 Three party conference handled by CAMEL CPH 

Figure 5.2.1.24 illustrates one example for establishment of a three party conference via CAMEL CPH.. 

A mobile CAMEL subscriber "A" sets up an outgoing call (1) to an ISDN subscriber ("B"). This call is recorded as 
outlined in clause 5.2.1.1. 

gsmSCF then invokes CPH operation 'initiate call attempt' (2). A new call segment (CS#2) with an outgoing leg "C" is 
created in MSC-A. 

MSC-A interrogates the HLR in order to determine the current location of subscriber "C" (3). The HLR shall create an 
interrogation record. 

MSC-A initiates set-up of an outgoing leg towards mobile subscriber "C" (4). MSC-A shall create an MOC record for 
the leg towards mobile subscriber "C". MSC-C shall create a MTC record for subscriber "C". 

gsmSCF then invokes CPH operation 'MoveLeg' to join all three legs in one call segment (5). MSC-A shall close the 
MOC record for call segment CS#2 to outgoing leg "C". The MOC record for the outgoing call of the mobile CAMEL 
subscriber "A" to ISDN subscriber "B" shall be updated to cover the additional outgoing CAMEL call leg "C". 

The following records are generated in HPLMN in this call scenario. 

Table 5.2.1.24: Records Generated for an Wake-up Call Handled by CAMEL CPH 



GMSC server 


MSC-A 


MSC-C 


HLR 


outgoing gateway record 


MOC record ("A", "B", "C") 


MTC record 


HLR interrogation record 




MOC record ("C") 
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Figure 5.2.1.24: Three Party Conference handled by CAMEL CPH 
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5.2.1 .25 Mobile Terminating Roaming Forwarding call after successful Retrieval of 
Routeing Information (MTRF) 

Figure 5.2.1.25 illustrates an incoming call to a PLMN subscriber "B" with roaming forwarding call after successful 
Retrieval of Routeing Information. 

The incoming call is first routed to a GMSC server (1). The GMSC server shall create an incoming gateway record for 
accounting purposes. 

The GMSC server interrogates the HLR of the called subscriber in order to determine his current known location (2). 
The HLR shall create an HLR interrogation CDR. 

The GMSC server routes the call to the MSC server at which the subscriber is currently registered (3). While on-going 
paging, this MSC server is requested to reroute the call towards a new MSC server (new MSC-B), applying "Mobile 
Terminating Roaming Forwarding call after successful Retrieval of Routeing Information" procedure (4). This MSC 
server (old MSC-B) shall create a MTRF record. 

The new MSC server (new MSC-B) shall create an MTC record for subscriber "B". 

The records generated are subsequently transferred to the Billing System of the PLMN (A). 

Table 5.2.1.25: Records Generated for Mobile Terminating Roaming Forwarding call after successful 

Retrieval of Routeing Information (MTRF) 



GMSC server 


Old MSC server 


New MSC server 


Incoming gateway record 


MTRF Record 


MTC record 
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Figure 5.2.1.25: mobile terminating roaming forwarding call after successful Retrieval of Routeing 

Information 
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5.2.1 .26 Mobile Terminating Roaming Forwarding call after successful Retrieval of 
Routeing Information (MTRF) to a roaming subscriber 

Figure 5.2.1.26 illustrates an incoming call to a PLMN subscriber "B" with roaming forwarding call after successful 
Retrieval of Routeing Information, and subscriber "B" is currently roaming in another PLMN 

The incoming call is first routed to a GMSC server (1). The GMSC server shall create an incoming gateway record for 
accounting purposes. 

The GMSC server interrogates the HLR of the called subscriber in order to determine his current known location (2). 
The HLR shall create an HLR interrogation CDR. 

The GMSC server routes the call to the MSC server at which the subscriber is currently registered (3). While on-going 
paging, this MSC server is requested to reroute the call towards a new MSC server (new MSC-B) in VPLMN in which 
subscriber "B" is actually located, applying "Mobile Terminating Roaming Forwarding call after successful Retrieval of 
Routeing Information" procedure (4). This MSC server (old MSC-B) shall create a MTRF record, and also a roaming 
record. These records may be used as a cross-check for the TAP information received from the VPLMN. 

The new MSC server (new MSC-B) shall create an MTC record for subscriber "B". 

The records generated are subsequently transferred to the Billing System of the appropriate PLMN (A). The MTC 
record generated by the terminating MSC server shall be employed to create the appropriate MTC TAP record. The 
TAP records shall be included in a TAP file and transmitted to the HPLMN (B). 

Table 5.2.1.26: Records Generated for Mobile Terminating Roaming Forwarding call after successful 

Retrieval of Routeing Information (MTRF) - Roaming 



GMSC server 


Old MSC server 


New MSC server 


Incoming gateway record 


MTRF Record 


MTC record 




Roaming Record 






s 



'^N© 



ISDN/PSTN 



HPLMN 



OldlVlSC-B -h:: 



©"■■-- 



Billing 
System 



© 



VPLMN 



New MSC-B 



Billing 
System 



.''^© 




n 

B 



Figure 5.2.1.26: mobile terminating roaming forwarding call after successful Retrieval of Routeing 

Information to a roaming subscriber 
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5.2.1 .27 Mobile Terminating Roaming Forwarding call after successful Retrieval of 
Routeing Information (MTRF), for a subscriber with Visiting Terminating 
Trigger Calls 



When a roaming forwarding call after successful Retrieval of Routeing Information (MTRF) procedure applies for a 
subscriber "B" having an active VT-CSI (stored in the VLR), on receiving the MSRN from the new MSC, the Old MSC 
releases dialog previously triggered with gsmSSF, and the new MSC subsequently applies the subscriber VT-CSI 
trigger to the resulting terminating call. 

The Old MSC shall generate a terminating CAMEL (TCR) record which contains VT-CSI triggering and release. 

The New MSC shall generate a terminating CAMEL (TCR) record which contains VT-CSI data. 

Table 5.2.1.27: Records Generated for Mobile Terminating Roaming Forwarding call after successful 

Retrieval of Routeing Information (MTRF) with VT-CSI 



GMSC server 


Old MSC server 


New MSC server 


Incoming gateway record 


Terminating CAIVIEL record 
(VT-CSI) 


Terminating CAIVIEL record 
(VT-CSI) 




IVITRF Record 


MTC Record 
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5.2.2 Diameter message flows 



Not applicable, as the separation of the CTF and CDF is not in the scope of the CS domain charging standards. Refer to 
clause 4.2 for further information. 

Vendors may nevertheless implement a separate CDCF and CCF for CS domain charging. In this case, the approach 
chosen shall conform to the principles and protocol applications specified in 3GPP TS 32.299 [50]. 



5.2.3 CDR generation 



In order to provide the data required for the management activities outlined in the previous clauses (billing, accounting, 
statistics, etc.), the CGF of the MSC server and/or Location Registers shall be able to produce a charging data record for 
each of the following: 

Mobile originated call attempt; 

Mobile originated emergency call attempt; 

Mobile originated, call forwarding attempt; 

Mobile terminated call attempt; 

Roaming call attempt in a gateway MSC server; 

Incoming call attempt in a gateway MSC server; 

Outgoing call attempt from a gateway MSC server; 

Transit call attempt; 

Terminating CAMEL call attempt; 

CAMEL CPH call attempts/call modifications; 

Supplementary service actions; 

HLR interrogation; 

Location updating (HLR and VLR); 

Short message service (point-to-point), mobile originated; 

Short message service (point-to-point), mobile terminated; 

Short message service (point-to-point), mobile originated interworking MSC server; 

Short message service (point-to-point), mobile terminated gateway MSC server; 

Common equipment usage; 

Mobile terminated location request; 

Mobile originated location request; 

Network induced location request. 

A more detailed description of the records is found in clause 6. L The detailed formal description of the data defined in 
the present document is to be found in 3GPP TS 32.298 [51]. 
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5.2.4 GTP' record transfer flows 

Not applicable, as the separation of the CDF and CGF is not in the scope of the CS domain charging standards. Refer to 
clause 4.2 for further information. 

Vendors may nevertheless implement a separate CCF and CGF for CS domain charging. In this case, the approach 
chosen shall conform to the principles and protocol applications specified in 3GPP TS 32.295 [54]. 

5.2.5 Be CDR file transfer 

There are two options for the transfer of the above CDRs to the Billing domain: 

1) use the file based interface specified in earlier 3GPP releases, as documented in annex A of the present 
document; 

2) apply the Rel-6 file based interface. Be, as specified in 3GPP TS 32.297 [52]. 

It is left to operator and vendor choice which one (or both) of the above interfaces to implement. 

5.3 CS donnain online charging scenarios 

CS domain charging is implemented by CAMEL techniques as described in 3GPP TS 23.078 [207] and 
3GPP TS 29.078 [212], i.e. outside the scope of the 32 series of charging TSs. 

5.3.1 Basic principles 

Void. Refer to clause 5.3. 

5.3.2 Diameter message flows 

Void. Refer to clause 5.3. 
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6 Definition of charging information 

This clause provides Stage 3 specifications of the CDR type and content for the 3GPP CS domain. For each of the CDR 
types listed in clause 5.2.3, a parameter table, which gives a short description of the parameters, is provided. The 
detailed specification of the CDR parameters and their encoding is contained in 3GPP TS 32.298 [51], while annex A 
and 3GPP TS 32.297 [52] specify the details of the CDR file ti'ansfer to the BD. 

6.1 Data description for CS domain offline charging 

6.1 .1 Diameter message contents 

Not applicable. Refer to clause 5.2.2 for further information. 

6.1 .2 GTP' message contents 

Not applicable. Refer to clause 5.2.4 for further information. 

6.1 .3 CDR description on tine Be reference point 

Dedicated types of CDRs can be generated in the CS domain, as specified in clause 5.2.3. The content of each CDR 
type is defined in one of the tables that are part of this clause. For each CDR type the parameter definition includes the 
parameter name, description and category. 

Editor's note: align the following text with 3GPP TS 32.240 [1]. 

Equipment vendors shall be able to provide all of the parameters listed in the CDR content table in order to claim 
compliance with the present document. However, since CDR processing and transport consume network resources, 
operators may opt to eliminate some of the parameters that are not essential for their operation. This operator 
provisionable reduction is specified by the parameter category. 

A parameter category can have one of two primary values: 

M This parameter is Mandatory and shall always be present in the CDR; 

C This parameter shall be present in the CDR only when certain Conditions are met. These Conditions are 
specified as part of the parameter definition. 

Some of these parameters are designated as Operator (O) provisionable. Using TMN management functions or specific 
tools provided by an equipment vendor, operators may choose, if they wish, to include or omit the parameter from the 
CDR. Once omitted, this parameter is not generated in a CDR. To avoid any potential ambiguity, a CDR generating 
element MUST be able to provide all these parameters. Only an operator can choose whether or not these parameters 
should be generated in its system. 

Those parameters that the operator may configure to be present or absent are further qualified with the "Operator 
provisionable" indicator as follows: 

Om This is a parameter that, if provisioned by the operator to be present, shall always be included in the CDRs. 
In other words, a Om parameter that is provisioned to be present is a mandatory parameter; 

Oc This is a parameter that, if provisioned by the operator to be present, shall be included in the CDRs when the 
required conditions are met. In other words, a Oc parameter that is configured to be present is a conditional 
parameter. 

The CS nodes shall be able to provide the CDRs at the Billing System interface in the format and content described in 
the present document. Additional CDR formats and contents, generated by the CS nodes, may be available at the 
interface to the billing system to meet the requirements of the billing system, these are outside of the scope of 3GPP 
standardization. 

The following tables provide a brief description of each CDR parameter. Full definitions of the parameters, sorted by 
the parameter name in alphabetical order, are provided in 3GPP TS 32.298 [51]. 3GPP TS 32.298 [51] also specifies the 
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encoding of the CDRs and their parameters on the B;. reference point, while the CDR files transferred on B;. are 
specified in 3GPP TS 32.297 [52]. 
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6.1.3.1 



Mobile originated call attempt 



If the generation of these records is enabled then an MOC record shall be created for each outgoing call attempt made 
by a mobile station. These MOC records shall be produced in the originating MSC. 

Table 6.1.3.1: MOC record 



Field 


2G 


3G 


Description 


Record Type 


M 


M 


Mobile originated. 


Served IMSI 


M 


M 


IMSI of the calling party. 


Served IMEI 


C 


C 


IMEI of the calling ME, if available. 


Served MSISDN 


Om 


Om 


The primary MSISDN of the calling party. 


Called Number 


M 


M 


The address of the called party i.e. the number dialled by the calling subscriber. 


Translated 
Number 


Oc 


Oc 


The called number after digit translation within the MSC (if applicable) 


Connected 
Number 


Oc 


Oc 


The number of the connected party if different to the Called Number 


Roaming Number 


Oc 


Oc 


The Mobile Station Roaming Number employed to route this connection, if applicable. 


Recording Entity 


M 


M 


The E.1 64 number of the visited MSC producing the record. 


Incoming TKGP 


Om 


Oc 


The MSC trunk group on which the call originated , usually from the BSS. If available in 
3G, this parameter shall be supplied. 


Outgoing TKGP 


Om 


Oc 


The trunk group on which the call left the MSC. If available in 3G, this parameter shall be 
supplied. 


Location 


M 


M 


The identity of the cell or the SAC at the time of CDR creation, including the location area 
code and MCC+MNC. 


Change of 
Location 


Oc 


Oc 


A list of changes in Location Area Code / Service Area Code / Cell Id and MCC+MNC. 
Each time-stamped. 


Basic service 


M 


M 


Bearer or teleservice employed. 


Rate Indication 


Oc 


Oc 


Present if "rate adaption" parameters for the basic service were signalled between the 
MS/UE and the network, see 3GPP TS 24.008 [208]. 


Transparency 
Indicator 


C 


C 


Indicates whether the basic service was used in transparent or non-transparent mode. 
This parameter is provided only for those basic services which may be employed in both 
transparent and non-transparent mode. 


Change Of Service 


Oc 


Oc 


A list of changes of basic service during a connection each time-stamped. 


Supp. Services 


C 


C 


Supplementary services invoked as a result of this connection. This field shall be present 
when one or more supplementary services have been invoked. 


AOC Parameters 


Oc 


Oc 


The charge advice parameters sent to the MS on call set-up. This field shall be supplied 
only when AoC parameters have been sent. 


Change of AOC 
Parameters 


Oc 


Oc 


New AOC parameters sent to the MS e.g. as a result of a tariff switch over, including the 
time at which the new set was applied. This field shall be supplied only when AoC 
parameters have been sent. 


IVIS Classmark 


M 


M 


The mobile station classmark employed on call set-up. 


Change of 
Classmark 


Oc 


Oc 


A list of changes to the classmark during the connection each time-stamped 


Event time 
stamps: 


C 
C 

Om 


C 
C 

Om 


Seizure time: time of incoming traffic channel seizure (for unsuccessful call attempts) 
Answer: time of answer (for successful calls) 
Release time: time of traffic channel release 


Call duration 


M 


M 


The chargeable duration of the connection for successful calls, the holding time for call 
attempts. 


Data volume 


C 


- 


The number of data segments transmitted if available at the MSC 


Radio Chan. 
Requested 


Om 


- 


The type of radio traffic channel (full / half etc.) requested by the MS. 


Radio Chan. Used 


M 


- 


The type of radio channel actually used (full or half rate). 


Change of Rad. 
Chan. 


Oc 


- 


A list of changes each time stamped 


Cause for 
termination 


M 


M 


The reason for the release of the connection. 


Diagnostics 


Om 


Om 


A more detailed reason for the release of the connection. 


Call reference 


M 


M 


A local identifier distinguishing between transactions on the same MS 


Sequence no. 


C 


C 


Partial record sequence number, only present in case of partial records. 


Additional Chg. 
Info 


Oc 


Oc 


Charge/no charge indicator and additional charging parameters, when available. 


Record extensions 


Oc 


Oc 


A set of network / manufacturer specific extensions to the record, when available. 


GsmSCF address 


C 


C 


Identifies the CAMEL server serving the subscriber. Shall be present only if CAMEL is 
applied. 
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Field 


2G 


3G 


Description 


Service key 


C 


c 


The CAMEL service logic to be applied. Shall be present only if CAMEL is applied. 


Network call 
reference 


C 


c 


An identifier to correlate transactions on the same call taking place in different network 
nodes, shall be present if CAMEL is applied. 


MSC Address 


c 


c 


This field contains the E.164 number assigned to the MSC that generated the network call 
reference. Shall be present only if CAMEL is applied. 


Default call 
handling 


Oc 


Oc 


Indicates whether or not a CAMEL call encountered default call handling. This field shall 
be present only if default call handling has been applied. 


Number of HSCSD 

Channels 

Requested 


c 




The maximum number of HSCSD channels requested as received from the MS at call set- 
up. Shall only be present for HSCSD connections. 


Number of HSCSD 

Channels 

Allocated 


c 




The number of HSCSD channels allocated to the MS at call set-up. Shall only be present 
for HSCSD connections. 


Change of HSCSD 
Parameters 


c 




A list of network or user initiated changes of number of HSCSD channels during a 
connection each time-stamped. Shall only be present in case of an HSCSD call, if the 
basic HSCSD parameters are modified due the user or network initiated modification 
procedure. 


Fixed Network 
User Rate 


Oc 


Oc 


Indicates the user data rate applied for the connection in the fixed network. Shall only be 
present for 2G HSCSD connections and for UMTS data connections. 


Air Interface User 
Rate Requested 


c 


- 


The total Air Interface User Rate Requested by the MS at call set-up. Shall only be present 
for non-transparent HSCSD connections. 


Channel Coding 
Accepted 


c 


- 


A list of the traffic channels codings accepted by the MS. Shall only be present for HSCSD 
connections. 


Channel Coding 
Used 


c 


- 


The traffic channels codings negotiated between the MS and the network at call set-up. 
Shall only be present for HSCSD connections. 


Guaranteed bit 
rate 




Oc 


Describes the bit-rate the UMTS bearer service shall guarantee to the user or application. 
Guaranteed Bit Rate may be used to facilitate admission control based on available 
resources, and for resource allocation within UMTS. Shall only be present for UMTS data 
connections. 


Maximum bit rate 




Oc 


Maximum Bit Rate can be used to make code reservations in the downlink of the radio 
interface. Its purpose is: 1) to limit the delivered bit-rate to applications or external 
networks with such limitations, 2) to allow maximum wanted user bit-rate to be defined for 
applications able to operate with different rates (e.g. applications with adapting codecs). 
Shall only be present for UMTS data connections. 


Speech Version 
Supported 


Om 


- 


Speech version supported by the MS with highest priority indicated by MS 


Speech Version 
Used 


Om 


- 


Speech version used for that call 


Number of DP 
encountered 


Oc 


Oc 


Number that counts how often armed detection points (TDP and EDP) were encountered. 
Shall be present only if CAMEL is applied. 


Level of CAMEL 
service 


Oc 


Oc 


Indicator for the complexity of the CAMEL feature used. Shall be present only if CAMEL is 
applied. 


Free format Data 


c 


C 


This field contains data sent by the gsmSCF in the Furnish Charging Information (FCI) 
message(s). The data can be sent either in one FCI message or several FCI messages 
with append indicator. Shall be present only if CAMEL is applied. 


CAMEL call leg 
information 


c 


C 


Set of CAMEL information lEs. Each of these lEs contains information related to one 
outgoing CAMEL call leg. Shall be present only if CAMEL is applied. 


Free format data 
append indicator 


c 


C 


Indicator if free format data from this CDR is to be appended to free format data in 
previous partial CDR. Shall be present only if CAMEL is applied. 


Default call 
handling 2 


Oc 


Oc 


Indicates whether or not a CAMEL call encountered default call handling for 2"^ service 
such as dialled service. This field shall be present only if default call handling has been 
applied. 


GsmSCF address 
2 


c 


C 


Identifies the CAMEL server serving the subscriber for 2™ service such as dialled service. 
Shall be present only if CAMEL is applied for 2"'' service. 


Service key 2 


c 


C 


The CAMEL service logic to be applied for 2"'' service such as dialled service. Shall be 
present only if CAMEL is applied for 2"^* service. 


Free format Data 2 


c 


C 


This field contains data sent by the gsmSCF in the FCI message(s) for 2"° service such as 
dialled service. The data can be sent either in one FCI message or several FCI messages 
with append indicator. Shall be present only if CAMEL is applied for 2""^ service. 


Free format data 
append indicator 2 


c 


C 


Indicator if free format data for 2™ service from this CDR is to be appended to free format 
data in previous partial CDR. Shall be present only if CAMEL is applied for 2"'' service. 


System Type 




M 


This field indicates the use of GERAN, UTRAN (or a value of unknown). This field is 
present when either the UTRAN or GERAN air-interface is used on call set-up. For an 
open CDR in a 2G NE (responsible for the CDR), the field is not present (even if the call is 
handed off to a 3G air interface). For a CDR in a 3G NE (responsible for the CDR), the 
value unknown shall be used after handover. 
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Field 


2G 


3G 


Description 


Location Routing 
Number (LRN) 


- 


Qc 


Location Routing Number for Number Portability feature 


LRN Source 
Indicator 


- 


Qc 


LRN Source Indicator tells the source of the LRN 


LRN Query Status 
Indicator 


- 


Qc 


Status of Number Portability query. 


JIP Parameter 


- 


Qc 


Jurisdiction Information Parameter 


JIP Source 
Indicator 


- 


Qc 


JIP Source Indicator tells the source of the JIP 


JIP Query Status 
Indicator 


- 


Qc 


Status of Number Portability query. 


Partial Record 
Type 


Qc 


Qc 


Indicates the event (time limit etc.) that caused the generation of a partial record. 


Reason for service 
change 


- 


Qc 


Indicates the type of service change and fallback. 


Service change 
initiator 


- 


Qc 


Indicates the service change initiator. 


Redial Attempt 


Qc 


Qc 


Indicates to the network that a call is the result of a redial attempt to switch from speech to 
multimedia or vice-versa 



£75/ 



3GPP TS 32.250 version 10.6.0 Release 10 



74 



ETSI TS 132 250 VI 0.6.0 (2013-01) 



6.1.3.2 



Mobile originated emergency call attempt 



If the generation of MOC records is enabled then an MOC emergency record shall be created for each outgoing 
emergency call attempt made by a mobile station. These records shall be produced in the originating MSC. 

Table 6.1.3.2: MOC emergency record 



Field 


2G 


3G 


Description 


Record 
Type 


M 


M 


Mobile originated. 


Served 
IMSI 


C 


C 


IMSI of the calling party in case of an emergency call with a SIM card. 


Served 
IMEI 


C 


C 


IMEI of the calling mobile equipment if available. 


Served 
MSISDN 


Oc 


Oc 


The primary MSISDN of the calling party, if supplied by the UE. 


Translated 
Number 


Oc 


Oc 


The called number after digit translation within the MSC (if applicable) 


Recording 
Entity 


M 


M 


The E.164 number of the visited MSC producing the record. 


Incoming 
TKGP 


Om 


Oc 


The MSC trunk group on which the call originated, usually from the BSS. If available In 3G, this 
parameter shall be supplied. 


Outgoing 
TKGP 


Om 


Oc 


The trunk group on which the call left the MSC. If available in 3G, this parameter shall be supplied. 


Location 


M 


M 


The identity of the cell or the SAC in which the call originated including the location area code and 
MCC+MNC. 


Change of 
Location 


Oc 


Oc 


A list of changes in Location Area Code / Service Area Code / Cell Id and MCC+MNC. Each time- 
stamped. 


Basic 
service 


M 


M 


Teleservice 'emergency call'. 


AOC 
Parameters 


Oc 


Oc 


The charge advice parameters sent to the MS on call set-up. This field shall be supplied only when 
AoC parameters have been sent. 


Change of 

AOC 

Parameters 


Oc 


Oc 


New AOC parameters sent to the MS e.g. as a result of a tariff switch over, including the time at 
which the new set was applied. This field shall be supplied only when AoC parameters have been 
sent. 


MS 
Classmark 


M 


M 


The mobile station classmark employed on call set-up. 


Change of 
classmark 


Oc 


Oc 


A list of changes to the classmark during the connection each time-stamped 


Event time 
stamps: 


C 

C 

Om 


C 

C 

Om 


Seizure time: time of incoming traffic channel seizure (for unsuccessful call attempts) 

Answer time: time of answer (for successful calls) 
Release time: time of traffic channel release 


Call 
duration 


M 


M 


The chargeable duration of the connection for successful calls, the holding time for call attempts. 


Radio 
Chan. 
Requested 


Om 




The type of radio traffic channel (full / half etc.) requested by the MS. 


Radio 
Chan. 
Used 


M 




The type of radio channel used (full or half rate). 


Change of 
Rad. Chan. 


Oc 


- 


A list of changes each time stamped 


Cause for 
termination 


M 


M 


The reason for the release of the connection. 


Diagnostics 


Om 


Om 


A more detailed reason for the release of the connection. 


Call 
reference 


M 


M 


A local identifier distinguishing between transactions on the same MS 


Sequence 
no. 


C 


C 


Partial record sequence number, only present in case of partial records. 


Record 
extensions 


Oc 


Oc 


A set of network/ manufacturer specific extensions to the record, when available. 


System 
Type 




M 


This field indicates the use of GERAN, UTRAN (or a value of unknown). This field is present when 
either the UTRAN or GERAN air-interface is used on call set-up. For an open CDR in a 2G NE 
(responsible for the CDR), the field is not present (even if the call is handed off to a 3G air 
interface). For a CDR in a 3G NE (responsible for the CDR), the value unknown shall be used after 
handover. 
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Field 


2G 


3G 


Description 


Partial 

Record 

Type 




Oc 


Indicates the event (time limit etc.) that caused the generation of a partial record. 
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6.1.3.3 



Mobile originated call forwarding attempt 



If the generation of MOC records is enabled in the forwarding MSC then the forwarding MSC shall produce an MOC 
record for the forwarded-leg of the call. 

Table 6.1.3.3: MOC, call forwarding record 



Field 


2G 


3G 


Description 


Record Type 


M 


M 


Mobile originated. 


Served IMSI 


M 


M 


IMSI of the calling party. 


Served MSISDN 


Om 


Om 


The MSISDN of the forwarding party. 


Calling Number 


Oc 


Oc 


The address of the calling party. 


Called Number 


M 


M 


The address of the "forwarded-to" party. 


Translated 
Number 


Oc 


Oc 


The called number after digit translation within the MSC (if applicable) 


Connected 
Number 


Oc 


Oc 


The number of the connected party if different to the Called Number 


Roaming Number 


Oc 


Oc 


The Mobile Station Roaming Number employed to route this connection, 
if applicable. 


Recording Entity 


M 


M 


The E.164 number of the forwarding MSC 


Incoming TKGP 


Om 


Om 


The MSC trunk group on which the call originated at the forwarding MSC. 


Outgoing TKGP 


Om 


Om 


The trunk group on which the call left the forwarding MSC 


Basic service 


C 


C 


Bearer or teleservJce employed, not always available e.g. in case of call forwarding 
unconditional. 


Rate Adaptation 


Oc 


Oc 


Present if "rate adaption" parameters for the basic service were signalled between the 
MS/UE and the network, see 3GPP TS 24.008 [208]. May not always be available in this 
CDR type. 


Transparency 
Indicator 


C 


C 


Indicates whether the basic service was used in transparent or non-transparent mode. This 
parameter is provided only for those basic services which may be employed in both 
transparent and non-transparent mode. 


Fixed Network 
User Rate 


Oc 


Oc 


Indicates the user data rate applied for the connection in the fixed network. Shall only be 
present for 2G HSCSD connections and for UMTS data connections. 


ChangeOfService 


Oc 


Oc 


A list of changes of basic service during a connection each time-stamped. 


Supplementary 
Services 


C 


C 


Supplementary services invoked as a result of this connection, if this information is available 
to the forwarding node. This field shall be present when one or more supplementary 
services have been invoked. 


Event time 
stamps: 


C 
C 

Om 


C 
C 

Om 


Seizure time: time of incoming traffic channel seizure (for unsuccessful call attempts) 
Answer time: time of answer (for successful calls) 
Release time: time of traffic channel release 


Call duration 


M 


M 


The chargeable duration of the connection for successful calls, the holding time of call 
attempts. 


Data volume 


C 


- 


The number of data segments transmitted if available at the MSC 


Cause for 
termination 


M 


M 


The reason for the release of the connection. 


Diagnostics 


Om 


Om 


A more detailed reason for the release of the connection. 


Call reference 


M 


M 


A local identifier distinguishing between transactions on the same MS 


Sequence no. 


C 


C 


Partial record sequence number, only present in case of partial records. 


Additional Chg. 
Info 


Oc 





Charge/no charge indicator and additional charging parameters, when available. 


Record 
extensions 


Oc 


Oc 


A set of network/ manufacturer specific extensions to the record, when available. 


GsmSCF 
address 


C 


C 


Identifies the CAMEL server serving the subscriber. Shall be present only if CAMEL is 
applied. 


Service key 


C 


C 


The CAMEL service logic to be applied. Shall be present only if CAMEL is applied. 


Network call 
reference 


C 


C 


An identifier to correlate transactions on the same call taking place in different network 
nodes, shall be present if CAMEL is applied. 


IVISC Address 


C 


c 


This field contains the E.164 number assigned to the MSC that generated the network call 
reference. Shall be present only if CAMEL is applied. 


CAMEL initiated 
CF indicator 


C 


c 


Indicates that the CAMEL server initiated call forwarding. Shall be present only if CAMEL is 
applied. 


Default call 
handling 


Oc 


Oc 


Indicates whether or not a CAMEL call encountered default call handling. This field shall be 
present only if default call handling has been applied. 


Number of DP 
encountered 


Oc 


Oc 


Number that counts how often armed detection points (TDP and EDP) were encountered. 
Shall be present only if CAMEL is applied. 
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Field 


2G 


3G 


Description 


Level of CAMEL 
service 


Qc 


Qc 


Indicator of the complexity of the CAMEL feature used. Shall be present only if CAMEL is 
applied. 


Free format Data 


C 


C 


This field contains data sent by the gsmSCF in the Furnish Charging Information (FCI) 
messages. The data can be sent either in one FCI message or several FCI messages with 
append indicator. Shall be present only if CAMEL is applied. 


CAMEL call leg 
information 


C 


C 


Set of CAMEL information lEs. Each of these lEs contains information related to one 
outgoing CAMEL call leg. Shall be present only if CAMEL is applied. 


Free format data 
append indicator 


c 


C 


Indicator if free format data from this CDR is to be appended to free format data in previous 
partial CDR. Shall be present only if CAMEL is applied. 


Default call 
handling 2 


Qc 


Qc 


Indicates whether or not a CAMEL call encountered default call handling for 2™ service 
such as dialled service. This field shall be present only if default call handling has been 
applied. 


GsmSCF 
address 2 


C 


C 


Identifies the CAMEL server serving the subscriber for 2"" service such as dialled service. 
Shall be present only if CAMEL is applied for 2"'' service. 


Service key 2 


c 


C 


The CAMEL service logic to be applied for 2"" service such as dialled service. Shall be 
present only if CAMEL is applied for 2"^ service. 


Free format Data 
2 


c 


C 


This field contains data sent by the gsmSCF in the FCI message(s) for 2™ service such as 
dialled service. The data can be sent either in one FCI message or several FCI messages 
with append indicator. Shall be present only if CAMEL is applied for 2""* service. 


Free format data 
append indicator 
2 


c 


C 


Indicator if free format data for 2"^ service from this CDR is to be appended to free format 
data in previous partial CDR. Shall be present only if CAMEL is applied for 2"*^ service. 


Location Routing 
Number (LRN) 


- 


Qo 


Location Routing Number for Number Portability feature 


LRN Source 
Indicator 


- 


Qc 


LRN Source Indicator tells the source of the LRN 


LRN Query 
Status Indicator 


- 


Qc 


Status of Number Portability query. 


JIP Parameter 


- 


Qc 


Jurisdiction Information Parameter 


JIP Source 
Indicator 


- 


Qc 


JIP Source Indicator tells the source of the JIP 


JIP Query Status 
Indicator 


- 


Qc 


Status of Number Portability query. 


Partial Record 
Type 


- 


Qc 


Indicates the event (time limit etc.) that caused the generation of a partial record. 
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6.1.3.4 



Mobile terminated call attempt 



If the generation of these records is enabled, then an MTC record shall be created for each incoming call attempt made 
for a mobile station. The MTC records shall be produced in the terminating MSC. 

Table 6.1.3.4: MTC record 



Field 


2G 


3G 


Description 


Record Type 


M 


M 


Mobile Terminated. 


Served IMSI 


M 


M 


IIVISI of the called party. 


Served IMEI 


C 


C 


IMEI of the called ME, if available. 


Served MSISDN 


Om 


Om 


The MSISDN of the called party. 


Calling Number 


C 


C 


The number of the calling party if available. 


Connected Number 


Oc 


Oc 


Only relevant in case of call forwarding where the "forwarded-to" number is recorded. 


Recording Entity 


M 


M 


The E.164 number of the visited (terminating) MSC 


Incoming TKGP 


Om 


Om 


The MSC trunk group on which the call originated. 


Outgoing TKGP 


Om 


Oc 


The trunk group on which the call left the MSC, usually to the BSS. If available in 3G, this 
parameter shall be supplied. 


Location 


C 


C 


The identity of the cell or the SAC occupied by the called party when the call was set up, 
including the location area code and MCC+MNC. 


Change of Location 


Oc 


Oc 


A list of changes in Location Area Code / Service Area Code / Cell Id and MCC+MNC. 
Each time-stamped. 


Basic Service 


M 


M 


Bearer or teleservice employed 


Rate Adaptation 


Oc 


Oc 


Present if "rate adaption" parameters for the basic service were signalled between the 
MS/UE and the network, see 3GPP TS 24.008 [208]. 


Transparency 
Indicator 


C 


C 


Indicates whether the basic service was used in transparent or non-transparent mode. 
This parameter is provided only for those basic services which may be employed in both 
transparent and non-transparent mode. 


Change of Service 


Oc 


Oc 


A list of changes of basic service during a connection each time-stamped. 


Supplementary 
services 


C 


C 


Supplementary services invoked as a result of this connection. This field shall be present 
when one or more supplementary services have been invoked. 


AOC Parameters 


Oc 


Oc 


The charge advice parameters sent to the MS on call set-up. This field shall be supplied 
only when AoC parameters have been sent. 


Change of AOC 
Parameters. 


Oc 


Oc 


New AOC parameters sent to the MS e.g. as a result of a tariff switch-over, including the 
time at which the new set was applied. This field shall be supplied only when AoC 
parameters have been sent. 


IVIS Classmark 


M 


M 


The mobile station class mark. 


Change of 
Classmark 


Oc 


Oc 


A list of changes to the classmark during the connection each time-stamped 


Event time stamps: 


C 
C 

Om 


C 
C 

Om 


Seizure time: time of traffic channel seizure for unsuccessful call attempts 
Answer time: time of answer for successful calls 
Release time: time of traffic channel release 


Call duration 


M 


M 


The chargeable duration of the connection if successful, the holding time of the call if 
unsuccessful. 


Data volume 


C 


- 


The number of data segments transmitted, if available at the MSC 


Radio Chan. 
Requested 


Om 


- 


The type of radio traffic channel (full / half etc.) requested by the MS. 


Radio Chan. Used 


M 


- 


The type of radio channel used (full or half rate). 


Change of Rad. 
Chan 


Oc 


- 


A list of changes each time stamped 


Cause for 
termination 


M 


M 


The reason for the release of the call. 


Diagnostics 


Om 


Om 


A more detailed reason for the release of the connection. 


Call reference 


M 


M 


A local identifier distinguishing between transactions at the same MS 


Sequence no. 


C 


C 


Partial record sequence number, only present in case of partial records. 


Additional Chg. Info 


Oc 


Oc 


Charge/no charge indicator and additional charging parameters, when available. 


Record extensions 


Oc 


Oc 


A set of network/ manufacturer specific extensions to the record, when available. 


Network call 
reference 


C 


C 


An identifier to correlate transactions on the same call taking place in different network 
nodes, shall be present if CAMEL is applied. 


IVISC Address 


C 


C 


This field contains the E.164 number assigned to the MSC that generated the network 
call reference. Shall be present only if CAMEL is applied. 


Number of HSCSD 

Channels 

Requested 


Oc 




The maximum number of HSCSD channels requested as received from the MS at call 
set-up. Shall only be present for HSCSD connections. 
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Field 


2G 


3G 


Description 


Number of HSCSD 
Channels Allocated 


Oc 


- 


The number of HSCSD channels allocated to the IVIS at call set-up. Shall only be present 
for HSCSD connections. 


Change of HSCSD 
Parameters 


Qc 




A list of network or user initiated changes of number of HSCSD channels during a 
connection each time-stamped. Shall only be present in case of an HSCSD call, if the 
basic HSCSD parameters are modified due the user or network initiated modification 
procedure. 


Fixed Network User 
Rate 


Qc 


- 


Indicates the user data rate applied for the connection in the fixed network. Shall only be 
present for 2G HSCSD connections and for UMTS data connections. 


Air Interface User 
Rate Requested 


C 


C 


The total Air Interface User Rate Requested by the IVIS at call set-up. Shall only be 
present for non-transparent HSCSD connections. 


Channel Coding 
Accepted 


C 


- 


A list of the traffic channels codings accepted by the IVIS. Shall only be present for 
HSCSD connections. 


Channel Coding 
Used 


C 


- 


The traffic channels codings negotiated between the MS and the network at call set-up. 
Shall only be present for HSCSD connections. 


Guaranteed bit rate 




Qc 


Describes the bit-rate the UMTS bearer service shall guarantee to the user or application. 
Guaranteed Bit Rate may be used to facilitate admission control based on available 
resources, and for resource allocation within UMTS. Shall only be present for UMTS data 
connections. 


IVIaximum bit rate 




Qc 


Maximum Bit Rate can be used to make code reservations in the downlink of the radio 
interface. Its purpose is: 

1 ) to limit the delivered bit-rate to applications or external networks with such limitations; 

2) to allow maximum wanted user bit-rate to be defined for applications able to operate 
with different rates (e.g. applications with adapting codecs). 

Shall only be present for UMTS data connections. 


Speech Version 
Used 


Qm 


- 


Speech version used for that call 


Speech Version 
Supported 


Qm 


- 


Speech version supported by the MS with highest priority indicated by MS. 


System Type 




M 


This field indicates the use of GERAN, UTRAN (or a value of unknown). This field is 
present when either the UTRAN or GERAN air-interface is used on call set-up. For an 
open CDR in a 2G NE (responsible for the CDR), the field is not present (even if the call 
is handed off to a 3G air interface). For a CDR in a 3G NE (responsible for the CDR), the 
value unknown shall be used after handover. 


Location Routing 
Number (LRN) 


- 


Oc 


Location Routing Number for Number Portability feature. 


LRN Source 
Indicator 


- 


Qc 


LRN Source Indicator tells the source of the LRN. 


LRN Query Status 
Indicator 


- 


Qc 


Status of Number Portability query. 


JIP Parameter 


- 


Qc 


Jurisdiction Information Parameter 


JIP Source 
Indicator 


- 


Qc 


JIP Source Indicator tells the source of the JIP. 


JIP Query Status 
Indicator 


- 


Qc 


Status of Number Portability query. 


Partial Record Type 


Qc 


Qc 


Indicates the event (time limit, etc.) that caused the generation of a partial record. 


Reason for service 
change 


- 


Qc 


Indicates the type of service change and fallback. 


Service change 
initiator 


- 


Qc 


Indicates the service change initiator. 
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6.1.3.5 



Roaming call attempt 



If the generation of these records is enabled then, a roaming record shall be created for each call redirected to a mobile 
subscriber roaming outside the HPLMN. These roaming records shall be produced in the GMSC of the roaming 
subscriber's HPLMN. These roaming records shall be produced by the "Old MSC/VLR" during Mobile Terminating 
Roaming Forwarding (MTRF) procedure, when the call is re-routed towards a new MSC/VLR located in a different 
PLMN. 

Table 6.1.3.5: Roaming record 



Field 


2G 


3G 


Description 


Record Type 


M 


M 


Roaming record. 


Served IMSI 


M 


M 


IMSI of the called (roaming) party. 


Served MSISDN 


Om 


Om 


The MSISDN of the called (roaming) party. 


Calling Number 


C 


C 


The address of the calling party, if available. 


Roaming Number 


M 


M 


The Mobile Station Roaming Number employed to route this connection. 


Recording Entity 


M 


M 


The E.164 number of the GMSC 


Incoming TKGP 


Om 


Om 


The GMSC/VMSC trunk group on which the call originated. 


Outgoing TKGP 


Om 


Om 


The trunk group on which the call left the GMSC/VMSC 


Basic service 


M 


M 


Bearer or teleservice employed. 


Transparency 
Indicator 


C 


C 


Indicates whether the basic service was used in transparent or non-transparent mode. 
This parameter is provided only for those basic services which may be employed in 
both transparent and non-transparent mode. 


ChangeOfService 


Oc 


Oc 


A list of changes of basic service during a connection each time-stamped. 


Supplementary 
Services 


C 


C 


Supplementary services invoked as a result of this connection. This field shall be 
present when one or more supplementary services have been invoked. 


Event time stamps 


C 
C 

Om 


C 
C 

Om 


Seizure time: time of incoming traffic channel seizure (for unsuccessful call attempts) 
Answer time: time of answer (for successful calls) 
Release time: time of traffic channel release 


Call duration 


M 


M 


The chargeable duration of the connection for successful calls, the holding time of call 
attempts. 


Data volume 


C 


C 


The number of data segments transmitted if available at the GMSC 


Cause for termination 


M 


M 


The reason for the release of the connection. 


Diagnostics 


Om 


Om 


A more detailed reason for the release of the connection. 


Call reference 


M 


M 


A local identifier distinguishing between transactions on the same MS 


Sequence no. 


C 


C 


Partial record sequence number, only present in case of partial records. 


Record extensions 


Oc 


Oc 


A set of network/ manufacturer specific extensions to the record, when available. 


Network call reference 


C 


C 


An identifier to correlate transactions on the same call taking place in different network 
nodes, shall be present if CAMEL is applied. 


MSC Address 


C 


C 


This field contains the E.164 number assigned to the MSC that generated the network 
call reference. Shall be present only if CAMEL is applied. 


Location Routing 
Number (LRN) 


- 


Oc 


Location Routing Number for Number Portability feature 


LRN Source Indicator 


- 


Oc 


LRN Source Indicator tells the source of the LRN 


LRN Query Status 
Indicator 


- 


Oc 


Status of Number Portability query. 


JIP Parameter 


- 


Oc 


Jurisdiction Information Parameter 


JIP Source Indicator 


- 


Oc 


JIP Source Indicator tells the source of the JIP 


JIP Ouery Status 
Indicator 


- 


Oc 


Status of Number Portability query. 


Partial Record Type 


- 


Oc 


Indicates the event (time limit, etc.) that caused the generation of a partial record. 
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6.1.3.6 



Incoming gateway call attempt 



If generation of these records is enabled, an incoming gateway record shall be created for each incoming call attempt 
received by a gateway MSC from another network. These records, produced in the gateway MSC, may be used to settle 
accounts with other networks. The generation of gateway records shall not be influenced by the production of MTC 
records i.e. even if the GMSC and terminating MSC are co-located a gateway record shall still be produced. 

Table 6.1.3.6: Incoming gateway record 



Field 


2G 


3G 


Description 


Record Type 


M 


M 


Incoming gateway record 


Calling Number 


C 


C 


The number of the calling party if available at this node. 


Called Number 


M 


M 


The address of the called party as seen by the GMSC. This is the number employed by 
the GMSC for routing. 


Recording Entity 


M 


M 


The E.1 64 number of the GMSC 


Incoming TKGP 


M 


M 


The incoming GMSC trunk group on which the call originated. 


Outgoing TKGP 


Qm 


Qc 


The trunk group on which the call left the GMSC. If available in 3G, this parameter shall 
be supplied. 


Event time stamps: 


M 
C 

Qm 


M 
C 

Qm 


Seizure time: time of incoming trunk seizure 
Answer time: time of answer (successful calls only) 
Release time: time of incoming trunk release 


Call duration 


M 


M 


The accountable duration (answer -> release of incoming trunk) of the connection if 
successful, the call holding time of the incoming trunk for call attempts. 


Data Volume 


C 


- 


If applicable and known at the GMSC 


ISDN Bearer 
Capability 


Qc 


Qc 


Present if this parameter is signalled back from the VMSC to the GMSC in the access 
transport parameter of the Answer Message (ANM), see 3GPP TS 29.007 [213]. 


Low Layer 
Compatibility 


Qc 


Qc 


Present if this parameter is signalled back from the VMSC to the GMSC in the access 
transport parameter of the Answer Message (ANM), see 3GPP TS 29.007 [213]. 


High Layer 
Compatibility 


Qc 


Qc 


Present if this parameter is signalled back from the VMSC to the GMSC in the access 
transport parameter of the Answer Message (ANM), see 3GPP TS 29.007 [213]. 


Cause for 
termination 


M 


M 


The reason for the release of the connection. 


Diagnostics 


Qm 


Qm 


A more detailed reason for the release of the connection. 


Call Reference 


M 


M 


A local identifier distinguishing between transactions. 


Reason for service 
change 


- 


Qc 


Indicates the type of service change and fallback. 


Service change 
initiator 


- 


Qc 


Indicates the service change initiator. 


Sequence no. 


C 


C 


Partial record sequence number, if applicable. 


Record extensions 


Qc 


Qc 


A set of network/ manufacturer specific extensions to the record, when available. 


Location Routing 
Number (LRN) 


- 


Qc 


Location Routing Number for Number Portability feature 


LRN Source 
Indicator 


- 


Qc 


LRN Source Indicator tells the source of the LRN 


LRN Query Status 
Indicator 


- 


Qc 


Status of Number Portability query. 


JIP Parameter 


- 


Qc 


Jurisdiction Information Parameter 


JIP Source Indicator 


- 


Qc 


JIP Source Indicator tells the source of the JIP 


JIP Query Status 
Indicator 


- 


Qc 


Status of Number Portability query. 


Partial Record Type 


- 


Qc 


Indicates the event (time limit, etc.) that caused the generation of a partial record. 
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6.1.3.7 



Outgoing gateway call attempt 



If generation of these records is enabled, an outgoing gateway record shall be created for each outgoing call attempt 
from a gateway MSC to another network. These records, produced in the gateway MSC, may be used to settle accounts 
with other networks. The generation of gateway records shall not be influenced by the production of MOC records 
i.e. even if the GMSC and originating MSC are co-located a gateway record shall still be produced. 

Table 6.1.3.7: Outgoing gateway record 



Field 


2G 


3G 


Description 


Record Type 


M 


M 


Outgoing gateway record 


Calling Number 


C 


C 


The number of the calling party if available at this node. 


Called Number 


M 


M 


The address of the called party as seen by the GIVISC. This is the number employed by 
the GMSC for routing. 


Recording Entity 


M 


M 


The E.164 number of the GMSC 


Incoming TKGP 


Qm 


Qc 


The incoming GMSC trunk group on which the call originated. If available in 3G, this 
parameter shall be supplied. 


Outgoing TKGP 


M 


M 


The trunk group on which the call left the GMSC. 


Event time stamps: 


M 
C 

Qm 


M 
C 

Qm 


Seizure time: time of outgoing trunk seizure 
Answer time: time of answer (successful calls only) 
Release time: time of outgoing trunk release 


Call duration 


M 


M 


The accountable duration (answer -> release of outgoing trunk) of the connection if 
successful, the call holding time of the outgoing trunk for call attempts. 


Data Volume 


C 


- 


If applicable and known at the GMSC 


Cause for termination 


M 


M 


The reason for the release of the connection. 


Diagnostics 


Qm 


Qm 


A more detailed reason for the release of the connection. 


Call Reference 


M 


M 


A local identifier distinguishing between transactions. 


Sequence no. 


C 


C 


Partial record sequence number, if applicable. 


Reason for service 
change 


- 


Qc 


Indicates the type of service change and fallback. 


Service change 
initiator 


- 


Qc 


Indicates the service change initiator. 


Record extensions 


Qc 


Qc 


A set of network/ manufacturer specific extensions to the record, when available. 


Location Routing 
Number (LRN) 


- 


Qc 


Location Routing Number for Number Portability feature 


LRN Source Indicator 


- 


Qc 


LRN Source Indicator tells the source of the LRN 


LRN Query Status 
Indicator 


- 


Qc 


Status of Number Portability query. 


JIP Parameter 


- 


Qc 


Jurisdiction Information Parameter 


JIP Source Indicator 


- 


Qc 


JIP Source Indicator tells the source of the JIP 


JIP Query Status 
Indicator 


- 


Qc 


Status of Number Portability query. 


Partial Record Type 


- 


Qc 


Indicates the event (time limit, etc.) that caused the generation of a partial record. 
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6.1.3.8 



Transit call attempt 



If generation of these records is enabled then a transit record may be generated for each incoming call attempt received 
by a Transit MSC i.e. neither originating nor terminating. For the avoidance of doubt, a transit record shall only be 
produced if no MOC or MTC record is produced for this call attempt by this MSC. The transit records, produced in the 
TMSC, may be used to record traffic from particular origins or to particular destinations. 

Table 6.1.3.8: Transit record 



Field 


2G 


3G 


Description 


Record Type 


M 


M 


Transit. 


Recording Entity 


M 


M 


The E.1 64 number of the transit IVISC 


Incoming TKGP 


M 


M 


The TMSC trunk group on which the call originated. 


Outgoing TKGP 


M 


M 


The trunk group on which the call left the TMSC. 


Calling Number 


C 


C 


The number of the calling party if available at this node. 


Called Number 


M 


M 


The address of the called party as seen by the TMSC. 


ISDN Basic Service 


Qm 


Qm 


The ISDN basic service employed 


Event time stamps: 


c 
c 

Qm 


C 
C 

Qm 


Seizure time: time of incoming trunk seizure for unsuccessful call attempts 
Answer time: time of answer (successful calls only) 
Release time: time of traffic channel release 


Call duration 


M 


M 


The chargeable duration of the connection if successful, the call holding time for 
call attempts. 


Data Volume 


C 


- 


If applicable and known at the transit MSC 


Cause for term. 


M 


M 


The reason for the release of the connection. 


Diagnostics 


Qm 


Qm 


A more detailed reason for the release of the connection. 


Call Reference 


M 


M 


A local identifier distinguishing between transactions. 


Sequence no. 


C 


C 


Partial record sequence number, if applicable. 


Record extensions 


Qc 


Qc 


A set of network/ manufacturer specific extensions to the record, when available. 


Location Routing Number 
(LRN) 


- 


Qc 


Location Routing Number for Number Portability feature 


LRN Source Indicator 


- 


Qc 


LRN Source Indicator tells the source of the LRN 


LRN Query Status Indicator 


- 


Qc 


Status of Number Portability query. 


JIP Parameter 


- 


Qc 


Jurisdiction Information Parameter 


JIP Source Indicator 


- 


Qc 


JIP Source Indicator tells the source of the JIP 


JIP Query Status Indicator 


- 


Qc 


Status of Number Portability query. 


Partial Record Type 


- 


Qc 


Indicates the event (time limit, etc.) that caused the generation of a partial 
record. 
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6.1 .3.9 Supplementary service actions 

A supplementary service record may be produced in the NEF of the appropriate MSC or HLR for each supplementary 
service action (activation, deactivation, invocation etc.) performed or initiated by the subscriber. 

• There are two fundamental types of SS-actions: Call related i.e. as a result of a connection e.g. Invocation of 
CLIP / CUR / AoC, etc. 

• Non-call related i.e. as a result of Subscriber Controlled Input (SCI) e.g. Registration of call forwarding. 

Each supplementary service action shall be performed on one or more basic service groups. If the action applies to all 
teleservices and all bearer services (i.e. to all basic services) then the basic services field shall be omitted. 

SCI actions may be recorded in individual SS-action records. Call related actions may be recorded in either the 
appropriate call record (MOC/MTC) or in separate SS-action records. 

Additional non-standard supplementary service actions may be made available within some networks in the form of 
Unstructured Supplementary Service Data (USSD). These actions may also be recorded in SS-action records. However, 
as these actions are non-standard they may not include an appropriate action type, supplementary service code or basic 
service code. 

Table 6.1.3.9: SS-action record 



Field 


2G 


3G 


Description 


Record Type 


M 


M 


Supplementary service action. 


Served IMSI 


M 


M 


The IMSI of the MS performing the action. 


Served IMEI 


Oc 


Oc 


The IMEI of the ME performing the action. 


Served MSISDN 


Om 


Om 


The primary MSISDN of the party performing the action. 


MS Classmark 


M 


M 


The mobile station classmark. 


Recording Entity 


M 


M 


The E.1 64 number of the visited MSC / HLR. 


Location 


Om 


Om 


The identity of the cell or the SAC, including the location area code and MCC+MNC, from 
which the request originated. 


Basic Services 


C 


C 


The basic service group(s) to which the supplementary service applies. This field is not 
provided if the action applies to all basic services. 


Supplementary 
Service 


C 


C 


The supplementary service or group of supplementary services for which the request was 
made. May not be available in case of USSD. 


SS Action 


c 


c 


Activation, deactivation, interrogation etc. May not be available in case of USSD. 


SS Action time 
stamp 


M 


M 


The time at which the action was requested. 


SS Parameters 


c 


C 


Service dependent parameters or unstructured supplementary service data, if defined for 
the SS action recorded in this CDR. 


SS Action Result 


c 


C 


Result of the requested transaction if unsuccessful. 


Call Reference 


M 


M 


A local identifier distinguishing between transactions at the same MS. 


Record extensions 


Oc 


Oc 


A set of network/ manufacturer specific extensions to the record, when available. 


System Type 


- 


M 


This field is present when either the UTRAN or GERAN air-interface is used. It is omitted 
when the service is provided by a GSM air interface 
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6.1 .3.10 HLR interrogation 

If enabled, a HLR interrogation record shall be created for each interrogation performed for a mobile subscriber. These 
records may be produced in either the HLR itself or the interrogating MSC. 

Table 6.1.3.10: HLR interrogation record 



Field 


2G 


3G 


Description 


Record Type 


M 


M 


HLR interrogation. 


Served IMSI 


C 


C 


The IMSI of the party being interrogated, if successful 


Served MSISDN 


M 


M 


The MSISDN of the subscriber being interrogated. 


Recording Entity 


M 


M 


The E.164 Number of the HLR / MSC. 


Basic Service 


Oc 


Oc 


Only for teleservice 21 (SMS-MT). 


Routing Number 


C 


C 


Routing number (MSRN, forwarding no.) provided by the HLR if the interrogation was 
successful. 


Interrogation time 
stamp 


M 


M 


Time at which the interrogation was invoked. 


Number of Forwarding 


C 


C 


The number of times the call has been forwarded if provided by ISUP. 


Interrogation Result 


C 


C 


The result of the interrogation request if unsuccessful. 


Record extensions 


Oc 


Oc 


A set of network/ manufacturer specific extensions to the record, when available. 



6.1 .3.1 1 Location update (VLR) 

If enabled, a VLR location update record shall be produced in the VLR for each location registration or location update 
received by the VLR for a mobile subscriber. 

Table 6.1.3.11 : Location update (VLR) record 



Field 


2G 


3G 


Loc 
Upd 
over 
SGs 


Description 


Record Type 


M 


M 


M 


Location update. 


Served IMSI 


M 


M 


M 


IMSI of the served MS. 


Served 
MSISDN 


Om 


Om 


Om 


The primary MSISDN of the party performing the location update 


Recording 
Entity 


M 


M 


M 


The E.1 64 number of the entity (VLR or MSC/VLR) generating the 
record. 


Old location 


C 
C 


C 
C 


C 


Not present for registration: 

VMSC E.164 Number 

Location Area Code and MCC+MNC 


New location 


M 

M 

Om 


M 

M 

Om 


M 

M 

Om 


VMSC E.164 Number . When E-UTRAN location update over SG, 
this field contains the E.164 number of the entity (VLR or MSC/VLR) 
generating the record (i.e Recording entity). 
Location Area Code 

Cell Identification or Service Area Code and MCC+MNC 
The Cell Identity contains the 16 least significant bits and the 
Tracking Area Code is placed in the Location Area Code field if E- 
UTRAN location update. 


Location 
Extension 


D - 


D - 


o„ 


The 12 most significant bits of the E-UTRAN 
Cell Identity are inclucieci if E-UTRAN 
location update. 


MS 
Classmark 


M 


M 


M 


The mobile station classmark. When E-UTRAN location update over 
SG, this field contains Default classmark 1" 0x7F value". 


Update time 
stamp 


M 


M 


M 


Time at which the update was invoked. 


Update 
Result 


C 


C 


C 


The result of the location update if unsuccessful. 


Record 
extensions 


Oc 


Oc 


Oc 


A set of network/ manufacturer specific extensions to the record, 
when available. 
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6.1.3.12 Location update (HLR) 

If enabled, an HLR location update record shall be produced in the HLR for each location registration or location 
update received by the HLR for a mobile subscriber including location updates received from subscribers roaming in 
foreign PLMNs. 

Table 6.1.3.12: Location Update (HLR) record 



Field 


2G 


3G 


Description 


Record Type 


M 


M 


Location update. 


Served IMSI 


M 


M 


IIVISI of the served MS. 


Recording Entity 


M 


M 


The E.1 64 Number of the HLR. 


Old location 


Oc 
Oc 


Oc 
Oc 


VMSC E.1 64 Number 
VLR E.1 64 Number 


New location 


M 
M 


M 
M 


VMSC E.1 64 Number 
VLR E.1 64 Number 


Update time stamp 


M 


M 


Time at which the update was invoked. 


Update Result 


C 


C 


The result of the location update if unsuccessful. 


Record extensions 


Oc 


Oc 


A set of network/ manufacturer specific extensions to the record, when available. 



6.1 .3.13 Short message service, mobile originated 

If enabled, an SMS-MO record shall be produced, within the originating MSC, for each short message sent by a mobile 
subscriber. 

Table 6.1.3.13: SMS-MO record 



^ Field 


2G 


3G 


SMS 
over 
SGs 


Description 


Record Type 


M 


M 


M 


SMS-Mobile originated. 


Served IMSI 


M 


M 


M 


The IMSI of the subscriber sending the short message. 


Served IMEI 


Oc 


Oc 


Oc 


The IMEI of the ME sending the message, if available. 


Served MSISDN 


Om 


Om 


Om 


The primary MSISDN of the subscriber sending the message. 


MS Classmark 


M 


M 


M 


The mobile station classmark. 


Service Centre 


M 


M 


M 


The address (E.1 64) of the SMS-service centre. 


Recording Entity 


M 


M 


M 


The E.1 64 number of the visited MSC. 


Location 


Om 


Om 


Om 


The Location Area Code and Cell Identity / Service Area Code and 
MCC+MNC_from which the message originated. The Cell Identity contains 
the 16 least significant bits and the Tracking Area Code is placed in the 
Location Area Code filed if E-UTRAN is used to deliver the SMS. 


Event Time stamp 


M 


M 


M 


Origination time: The time at which the message was received by the 
MSC from the subscriber. 


Message Reference 


M 


M 


M 


A reference, provided by the MS uniquely identifying this message. 


SMS Result 


C 


C 


C 


The result of the attempted delivery if unsuccessful. 


Record extensions 


Oc 


Oc 


Oc 


A set of network/ manufacturer specific extensions to the record, when 
available. 


Destination number 


Om 


Om 


Om 


The destination number dialled by the MS sending the short message. 


CAMELSMSInformation 


C 


C 


C 


Set of CAMEL information lEs. Each of these lEs contains information 
related to CAMEL call leg related for the SMS. Shall be present only if 
CAMEL is applied. 


System Type 




M 


M 


This field is present when either the UTRAN or GERAN air-interface is 
used. It is omitted when the service is provided by a GSM air interface. 
The field shall be set to "unknown" for SMS delivery using E-UTRAN. 


Location Extension 


- 


- 


Om 


The 1 2 most significant bits of the E-UTRAN Cell Identity are included if 
E-UTRAN is used to deliver the SMS. 
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6.1 .3.14 Short message service, mobile terminated 

If enabled, an SMS-MT record shall be produced, within the terminating MSC, for each short message received by a 
mobile subscriber. 

Table 6.1.3.14: SMS-MT record 



Field 


2G 


3G 


SMS 
over 
SGs 


Description 


Record Type 


M 


M 


M 


SMS-Mobile Terminated. 


Service Centre 


M 


M 


M 


The E.164 address of the SMS centre. 


Served IMS! 


M 


IVI 


IVI 


The IMSI of the receiving party. 


Served IMEI 


Oc 


Oc 


Oc 


The IMEI of the receiving party, if available. 


Served MSISDN 


Om 


Om 


Om 


The MSISDN of the receiving party. 


MS Classmarl< 


M 


C 


C 


The mobile station classmark. 


Recording Entity 


M 


M 


M 


The E.164 number of the visited MSC. 


Location 


Om 


Om 


Om 


The Location Area Code and Cell Identity /Service Area Code and 
MCC+MNCjo which the message was delivered. The Cell Identity contains 
the 1 6 least significant bits and the Tracking Area Code is placed in the 
Location Area Code filed if E-UTRAN is used to deliver the SMS. 


Event time stamp 


IVl 


M 


M 


Delivery time: time at which message was sent to the MS by the MSC. 


SIVIS Result 


C 


C 


C 


The result of the attempted delivery if unsuccessful. 


Record extensions 


Oc 


Oc 


Oc 


A set of network/ manufacturer specific extensions to the record, when 
available. 


System Type 


C 


M 


M 


This field is present when either the UTRAN or GERAN air-interface is 
used. It is omitted when the service is provided by a GSM air interface. The 
field shall be set to "unknown" for SMS delivery using E-UTRAN. 


CAIVlELSIVlSlnformation 


C 


C 


C 


Set of CAMEL information lEs. Each of these lEs contains information 
related to CAMEL call leg related for the SMS. Shall be present only if 
CAMEL is applied. 


Location Extension 


- 


- 


Om 


The 1 2 most significant bits of the E-UTRAN Cell Identity are included if E- 
UTRAN is used to deliver the SMS. 



6.1 .3.15 SMS-MO interworking record 

If enabled, an SMS-MO interworking record shall be produced, within the interworking MSC, for each short message 
generated by a mobile subscriber. These records may be used to settle accounts between PLMNs and SMS service 
centres. Where the Interworking MSC is also the originating MSC, an SMS-MO CDR will also be generated. 

Table 6.1.3.15: SMS-MO interworking record 



Field 


2G 


3G 


Description 


Record Type 


M 


M 


SMS-MO interworking record. 


Service Centre 


M 


M 


The E.164 address of the SMS service centre. 


Served IMSI 


M 


M 


The IMSI of the sending party. 


Recording Entity 


M 


M 


The E.164 number of the visited MSC. 


Event Time stamp 


M 


M 


The time at which the message was received by the interworking function. 


SMS Result 


C 


C 


The result of the attempted delivery if unsuccessful, when available. 


Record extensions 


Oc 


Oc 


A set of network/ manufacturer specific extensions to the record. 
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6.1 .3.16 SMS-MT gateway record 

If enabled, an SMS-MT gateway record shall be produced, within the gateway MSC, for each short message sent to a 
mobile subscriber. Where the Gateway MSC is also the terminating MSC, an SMS-MT CDR will also be generated. 

Table 6.1.3.16: SMS-MT gateway record 



Field 


2G 


3G 


Description 


Record Type 


M 


M 


SIVIS-IVIT gateway record. 


Service Centre 


M 


M 


The E.I 64 address of tlie SIVIS service centre. 


Served IMSI 


M 


M 


The IMSI of the receiving party. 


Served MSISDN 


Om 


Om 


The IVISISDN of the receiving party. 


Recording Entity 


M 


M 


The E.1 64 number of the visited MSC. 


Event Time stamp 


M 


M 


The time at which the message was received by the gateway. 


SIVIS Result 


C 


C 


The result of the attempted delivery if unsuccessful. 


Record extensions 


Oc 


Oc 


A set of network/ manufacturer specific extensions to the record, when available. 



6.1 .3.17 Common equipment usage record 

If enabled, a common equipment usage record shall be created in the VMSC to record the usage (duration) of common 
equipment, e.g. conference circuits, employed by a mobile subscriber. 

Table 6.1.3.17: Common equipment usage record 



Field 


20 


3G 


Description 


Record Type 


M 


M 


Common equipment usage record. 


Equipment type 


M 


M 


e.g. Conference circuit. 


Equipment Id. 


C 


C 


The local id. Of the equipment employed. 


Served IMSI 


M 


M 


The IMSI of the party responsible for the seizure of the equipment.. 


Served MSISDN 


Om 


Om 


The primary MSISDN of the served party.. 


Recording Entity 


M 


M 


The E.1 64 number of the MSC in which the equipment is located. 


Basic service 


C 


C 


Bearer or teleservice employed, if appropriate. 


Rate Adaptation 


Oc 


Oc 


Present if "rate adaption" parameters for the basic service were signalled between the 
MS/UE and the network, see 3GPP TS 24.008 [208]. 


Fixed Network 
User Rate 


Oc 


Oc 


Indicates the user data rate applied for the connection in the fixed network. Shall only be 
present for 2G HSCSD connections and for UMTS data connections. 


ChangeOfService 


Oc 


Oc 


A list of changes of basic service during a connection each time-stamped. 


Supp. Services 


C 


C 


Supplementary services invoked in connection with this equipment. 


Event Time Stamp 


M 

Om 


M 

Om 


Seizure time: the time at which the equipment was seized. 
Release time: the time at which the equipment was released. 


Call Duration 


M 


M 


The total duration of the usage of the equipment. 


Call Reference 


M 


M 


A local identifier distinguishing between transactions. 


Sequence no. 


C 


C 


Partial record sequence number if applicable. 


Record extensions 


Oc 


Oc 


A set of network/ manufacturer specific extensions to the record, when available. 


System Type 




M 


This field indicates the use of GERAN, UTRAN (or a value of unknown). This field is 
present when either the UTRAN or GERAN air-interface is used on call set-up. For an 
open CDR in a 2G NE (responsible for the CDR), the field is not present (even if the call is 
handed off to a 3G air interface). For a CDR in a 3G NE (responsible for the CDR), the 
value unknown shall be used after handover. 


Partial Record 
Type 


- 


Oc 


Indicates the event (time limit etc.) that caused the generation of a partial record. 
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6.1 .3.1 8 Terminating CAMEL call attempt 

If the generation of these records is enabled, a terminating CAMEL call attempt record shall be generated for each call 
toward a subscriber with a T-CSI or VT-CSI and if the terminating trigger criteria are met. The record is generated in 
the GMSC/gsmSSF carrying out the terminating CAMEL call handling and in the MSC server/gsmSSF carrying out the 
visited terminating CAMEL call attempt. 

Table 6.1.3.18: Terminating CAMEL record 



Field 


2G 


3G 


Description 


Record Type 


M 


M 


Terminating CAMEL interrogation. 


Served IMSI 


M 


M 


IMSI of the called party 


Served MSISDN 


Om 


Om 


The MSISDN of the called party. 


Recording Entity 


M 


M 


The E.1 64 number of the GMSC. 


Interrogation time 
stamp 


M 


M 


Time at which the interrogation was invoked. 


CAMEL 

Destination 

Number 


M 


M 


The number available for routing after the CAMEL server enquiry. 


GsmSCF Address 


M 


M 


The CAMEL server serving the subscriber. 


Service key 


M 


M 


The CAMEL service logic to be applied. 


Network call 
reference 


M 


M 


An identifier to correlate transactions on the same call taking place in different network 
nodes. 


MSC Address 


M 


M 


This field contains the E.1 64 number assigned to the MSC that generated the network call 
reference. 


Default call 
handling 


Oc 


Oc 


Indicates whether or not a CAMEL call encountered default call handling. This field shall 
be present only if default call handling has been applied. 


Record extensions 


Oc 


Oc 


A set of network/ manufacturer specific extensions to the record, when available. 


Called Number 


M 


M 


The address of the called party as received by the GMSC/gsmSSF. 


Calling Number 


C 


C 


The address of the calling party, if available. 


Incoming TKGP 


Om 


Oc 


The GMSC trunk group on which the call originated. If available in 3G, this parameter 
shall be supplied. 


Outgoing TKGP 


Om 


Oc 


The trunk group on which the call left the GMSC. If available in 3G, this parameter shall 
be supplied. 


Event time stamps: 


C 
C 

Om 


C 
C 

Om 


Seizure time: time of incoming traffic channel seizure (for unsuccessful call attempts) 
Answer time: time of answer (for successful calls) 
Release time: time of traffic channel release 


Call duration 


M 


M 


The chargeable duration of the connection for successful calls, the holding time of call 
attempts. 


Data volume 


C 


- 


The number of data segments transmitted if available at the GMSC 


Cause for 
termination 


M 


M 


The reason for the release of the connection. 


Diagnostics 


Om 


Om 


A more detailed reason for the release of the connection. 


Call reference 


M 


M 


A local identifier distinguishing between transactions on the same MS 


Sequence no. 


C 


C 


Partial record sequence number, only present in case of partial records. 


Number of DP 
encountered 


Oc 


Oc 


Number that counts how often armed detection points (TDP and EDP) were encountered. 


Level of CAMEL 
service 


Oc 


Oc 


Indicator of the complexity of the CAMEL feature used. 


Free format Data 


C 


C 


This field contains data sent by the gsmSCF in the Furnish Charging Information (FCI) 
message(s). The data can be sent either in one FCI message or several FCI messages 
with append indicator. 


CAMEL call leg 
information 


C 


C 


Set of CAMEL information lEs. Each of these lEs contains information related to one 
outgoing CAMEL call leg. 


Free format data 
append indicator 


c 


C 


Indicator if free format data from this CDR is to be appended to free format data in 
previous partial CDR. 


MSC server 
indication 


c 


C 


Indication if the CAMEL call handling is active in the MSC server. 


Default call 
handling 2 


Oc 


Oc 


Indicates whether or not a CAMEL call encountered default call handling for 2"'^ service 
such as dialled service. This field shall be present only if default call handling has been 
applied. 


GsmSCF address 
2 


C 


C 


Identifies the CAMEL server serving the subscriber for 2™ service such as dialled service. 
Shall be present only if CAMEL is applied for 2"^^ service. 


Service key 2 


c 


C 


The CAMEL service logic to be applied for 2"'^ service such as dialled service. Shall be 
present only if CAMEL is applied for 2"^* service. 
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Field 


2G 


3G 


Description 


Free format Data 2 


C 


C 


This field contains data sent by the gsmSCF in the FCI message(s) for 2™ service such as 
dialled service. The data can be sent either in one FCI message or several FCI messages 
with append indicator. Shall be present only if CAMEL is applied for 2"'' service. 


Free format data 
append indicator 2 


C 


C 


Indicator if free format data for 2™ service from this CDR is to be appended to free format 
data in previous partial CDR. Shall be present only if CAMEL is applied for 2"'^ service. 


Location Routing 
Number (LRN) 


- 


Qc 


Location Routing Number for Number Portability feature 


LRN Source 
Indicator 


- 


Qc 


LRN Source Indicator tells the source of the LRN 


LRN Query Status 
Indicator 


- 


Qc 


Status of Number Portability query. 


JIP Parameter 


- 


Qc 


Jurisdiction Information Parameter 


JIP Source 
Indicator 


- 


Qc 


JIP Source Indicator tells the source of the JIP 


JIP Query Status 
Indicator 


- 


Qc 


Status of Number Portability query. 


Partial Record 
Type 


Qc 


Qc 


Indicates the event (time limit etc.) that caused the generation of a partial record. 



6.1.3.19 



IMEI observation ticket 



An observed IMEI ticket is generated whenever greylisted, blacklisted or non-white listed mobile equipment is detected 
during an IMEI check. The purpose of the ticket is to link the mobile equipment under observation with its current user 
(IMSI). The ticket also includes information describing when and where the equipment was used to enable the tracking 
of such equipment. Finally, if the ticket was triggered by a call attempt, a call reference is provided in order to locate the 
corresponding call record. 

The IMEI tickets are generated by the NEF of the MSC performing the IMEI check. 

Table 6.1.3.19: IMEI ticket 



Field 


20 


3G 


Description 


Served IMEI 


M 


M 


IMEI of the observed mobile equipment 


IMEI Status 


M 


M 


The result of the IMEI check e.g. blacklisted, greylisted, unknown. 


Served IMSI 


M 


M 


The IMSI of the subscriber currently using the mobile equipment. 


Served 
MSISDN 


C 


C 


The MSISDN of the subscriber currently using the observed mobile equipment, only available if 
the event that triggered the IMEI check was an MQC, MTC, SMS-MQ or SMS-MT 


Recording 
Entity 


M 


M 


The E.164 number of the recording MSC. 


Event Time 
Stamp 


M 


M 


The time at which the IMEI check was performed. 


Location 


M 


M 


The location area code and cell identity of the cell and MCC+MNC from which the mobile 
equipment was used. 


IMEI Check 
Event 


Qm 


Qm 


The event that caused IMEI checking to take place 


Call 
Reference 


Qc 


Qc 


Qnly available if the IMEI check was related to an MQC or MTC 


Record 
extensions 


Qc 


Qc 


A set of network/ manufacturer specific extensions to the record, when available. 
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6.1 .3.20 Mobile terminated location request (MT-LR) 

If enabled, an LCS-MT record shall be produced, within the visited MSC, for each mobile a terminated location request 
is performed for. 

Table 6.1.3.20: LCS-MT record 



Field 


2G 


3G 


Description 


Record Type 


M 


M 


LCS-MT record. 


Recording Entity 


M 


M 


The E.I 64 number of the visited MSC producing the record. 


LCS Client Type 


M 


M 


The type of the LCS client that invoked the LR. 


LCS Client Identity 


M 


M 


Further identification of the LCS client . 


Served IMSI 


C 


C 


The IMSI of the subscriber the LR is invoked for, if available. See NOTE 


Served MSISDN 


C 


C 


The MSISDN of the subscriber the LR is invoked for, if available. See NOTE 


Served IMEI 


c 


C 


The IMEI of the susbcriber the LR is invoked for, if available. See NOTE 


Location Type 


M 


M 


The type of the location request. 


LCS QoS 


C 


C 


OoS of the LR, if available. 


LCS Priority 


C 


C 


Priority of the LR, if available. 


IVILC Number 


M 


M 


The E.164 address of the requesting GMLC. 


Event Time Stamp 


M 


M 


The time at which the LR was received by the MSC. 


MeasureDuration 


Om 


Om 


The duration of proceeding the location request . 


Notification To IVIS 
User 


C 


C 


The privacy notification to MS user that was applicable when the LR was invoked, if 
available. 


Privacy Override 


c 


C 


This parameter indicates if MS privacy was overridden by the LCS client, if available. 


Location 


Om 


- 


The LAC and CI and MCC+MNC when the LR is received. 


Location Estimate 


Oc 


Oc 


The location estimate for the subscriber if contained in geographic position and the LR 
was successful. 


Positioning Data 


C 


c 


The positioning method used or attempted, if available. 


LCS Cause 


Oc 


Oc 


The result of the LR if any failure or partial success happened as known at the radio 
interface. 


Cause for 
Termination 


M 


M 


The reason for the termination of the location service. 


Diagnostics 


C 


C 


A more detailed information about the Cause for Termination if any failure or partial 
success happened. 


System Type 


- 


M 


This field indicates the use of GERAN or UTRAN at the time of the LCS request. This 
field is present when either the UTRAN or GERAN air-interface is used on call set-up. 


Record extensions 


Oc 


Oc 


A set of network/ manufacturer specific extensions to the record. 


NOTE: at least one: IMSI, MSISDN or IMEI, shall be present. 
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6.1 .3.21 Mobile originated location request (MO-LR) 

If enabled, an LCS-MO record shall be produced, within the visited MSC, for each mobile an originated location 
request is performed for. 

Table 6.1.3.21 : LCS-MO record 



Field 


2G 


3G 


Description 


Record Type 


M 


M 


LCS-MO record. 


Recording Entity 


M 


M 


The E.164 number of the visited IVISC producing the record. 


LCS Client Type 


C 


C 


The type of the LCS client that invoked the LR, if available. 


LCS Client Identity 


C 


C 


Further identification of the LCS client, if available. 


Served IMSI 


M 


M 


The IIVISI of the subscriber the LR is invoked for. 


Served MSISDN 


Om 


Om 


The IVISISDN of the subscriber the LR is invoked for. 


MOLR Type 


M 


M 


The type of the LR. 


LCS QoS 


C 


C 


OoS of the LR, if available. 


LCS Priority 


Oc 


Oc 


Priority of the LR, if available. 


IVILC Number 


C 


c 


The E.164 address of the involved GIVILC, if available. 


Event Time Stamp 


M 


M 


The time at which the LR was received by the IVISC. 


MeasureDuration 


Om 


Om 


The duration of proceeding the location request . 


Location Estimate 


Oc 


Oc 


The location estimate for the subscriber if contained in geographic position and the LR 
was successful. 


Positioning Data 


C 


C 


The positioning method used or attempted, if available. 


LCS Cause 


C 


c 


The result of the LR if any failure or partial success happened as known at the radio 
interface. 


Cause for 
Termination 


M 


M 


The reason for the termination of the location service. 


Diagnostics 


C 


C 


A more detailed information about the Cause for Termination if any failure or partial 
success happened. 


System Type 


- 


M 


This field indicates the use of GERAN or UTRAN at the time of the LCS request. This field 
is present when either the UTRAN or GERAN air-interface is used on call set-up. 


Record extensions 


Oc 


Oc 


A set of network/ manufacturer specific extensions to the record. 
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6.1 .3.22 Network induced location request (NI-LR) 

If enabled, an LCS-NI record shall be produced, within the visited MSC, for each network induced location request 
performed for a MS e.g. in case of emergency call. 

Table 6.1.3.22: LCS-NI record 



Field 


2G 


3G 


Description 


Record Type 


M 


M 


LCS-NI record. 


Recording Entity 


M 


M 


The E.164 number of the visited MSC producing the record. 


LCS Client Type 


C 


C 


The type of the LCS client that invoked the LR, if available. 


LCS Client Identity 


C 


C 


Further identification of the LCS client, if available. 


Served IMSI 


c 


c 


The IMSI of the calling party the LR is executed for if supplied by the UE. 


Served MSISDN 


c 


c 


The MSISDN of the calling party the LR is executed for if supplied by the UE. 


Served IMEI 


c 


c 


The IMEI of the calling party the LR is executed for if available. 


EMS-Digits 


Oc 


Oc 


The emergency service routing digits, if emergency call. 


EMS-Key 


Oc 


Oc 


The emergency service routing key, if emergency call. 


LCS QoS 


C 


c 


OoS of the LR, if available. 


LCS Priority 


C 


c 


Priority of the LR, if available. 


IVILC Number 


C 


c 


The E.164 address of the involved GMLC, if available. 


Event Time Stamp 


M 


M 


The time at which the LR was received by the MSC. 


MeasureDuration 


Om 


Om 


The duration of proceeding the location request . 


Location Estimate 


Oc 


Oc 


The location estimate for the subscriber if contained in geographic position and the LR 
was successful. 


Positioning Data 


C 


C 


The positioning method used or attempted, if available. 


LCS Cause 


C 


c 


The result of the LR if any failure or partial success happened as known at the radio 
interface. 


Cause for 
Termination 


M 


M 


The reason for the termination of the location service. 


Diagnostics 


C 


C 


A more detailed information about the Cause for Termination if any failure or partial 
success happened. 


System Type 


- 


M 


This field indicates the use of GERAN or UTRAN at the time of the LCS request. This field 
is present when either the UTRAN or GERAN air-interface is used on call set-up. 


Record extensions 


Oc 


Oc 


A set of network/ manufacturer specific extensions to the record. 
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6.1 .3.23 Mobile originated call attempt (CAMEL CPH adapted version) 

If the MSC / gsmSCF is able to provide CAMEL CPH services, this kind of record shall replace records according to 
section 6.1.3.1 Mobile originated call attempt. This applies to all mobile originated call attempts, even if no CPH 
operations are used in the individual call. Record fields that are specific to individual outgoing legs are recorded in the 
grouped field 'Camel Call Leg Information' . 

If the generation of this kind of record is enabled then the MSC shall produce one MOC record. The incoming leg is 
recorded in the main body. Whenever there is a CAMEL dialogue, outgoing legs of the same call segment are recorded 
in the grouped field "CAMEL call leg information". Further legs in new call segments are recorded in CDRs of type 
"6.1.3.25 New Call Segment in a MO, CF or MT CAMEL Dialogue". 

Examples for call situations where this type of record applies are the following: 

Mobile originating call without CPH being involved. 

Mobile originating call continuing after disconnect of the incoming leg in case of no partial record generation. 
When partial records are generated, they are of type"6. 1.3.25 New Call Segment in a MO, CF or MT CAMEL 
Dialogue", 

Mobile originating call with more than one outgoing leg on this call segment. 

Mobile originating call in which the original outgoing leg has been disconnected by gsmSCF. 

Disconnect of the incoming leg is recorded by filling the related record fields in the main body of the record. Optionally 
a partial record may be generated. This partial record is of type "6.1.3.24 gsmSSF initiated CAMEL CPH call attempt". 

Disappearing (DisconnectLeg, SplitLeg, etc.) of an outgoing leg is recorded by filling the related record fields in the 
'Camel Call Leg Information' field for the disappearing leg. Optionally a partial record may be generated. This partial 
record does not contain information of the leg that disappeared, i.e. it does not contain a 'Camel Call Leg Information' 
field for that leg. 

Connection of a further leg to this call segment is recorded by adding a further field 'Camel Call Leg Information'. 
Optionally a partial record may be generated. 

Table 6.1.3.23: MOC record (CAMEL CPH adapted version) 



r Field 


2G 


3G 


Description 


Record Type 


M 


M 


Mobile originated. 


Served IMSI 


M 


M 


IMSI of the calling party. 


Served IMEI 


C 


C 


IMEI of the calling ME, if available. 


Served MSISDN 


Om 


Om 


The primary MSISDN of the calling party. 


Called Number 


M 


M 


The address of the called party i.e. the number dialled by the calling subscriber. 


Recording Entity 


M 


M 


The E.1 64 number of the visited MSC producing the record. 


Incoming TKGP 


Om 


Oc 


The MSC trunk group on which the call originated, usually from the BSS. If available in 
3G, this parameter shall be supplied. 


Location 


M 


M 


The identity of the cell or the SAC and MCC+MNC at the time of CDR creation, including 
the location area code. 


Change of 
Location 


Oc 


Oc 


A list of changes in Location Area Code / Service Area Code / Cell Id and MCC+MNC. 
Each time-stamped. 


Basic service 


M 


M 


Bearer or teleservice employed, 'speech' in case of CAMEL CPH calls. 


Supp. Services 


C 


C 


Supplementary services invoked as a result of this connection. This field shall be present 
when one or more supplementary services have been invoked. 


AOC Parameters 


Oc 


Oc 


The charge advice parameters sent to the MS on call set-up. This field shall be supplied 
only when AoC parameters have been sent. 


Change of AOC 
Parameters 


Oc 


Oc 


New AOC parameters sent to the MS e.g. as a result of a tariff switch over, including the 
time at which the new set was applied. This field shall be supplied only when AoC 
parameters have been sent. 


IVIS Classmark 


M 


M 


The mobile station classmark employed on call set-up. 


Change of 
Classmark 


Oc 


Oc 


A list of changes to the classmark during the connection each time-stamped. 


Event time 
stamps: 


C 
C 

Om 


C 
C 

Om 


Seizure time: time of incoming traffic channel seizure (for unsuccessful call attempts) 
Answer: time of answer (for successful calls) 
Release time: time of traffic channel release 
for the incoming leg. 



£75/ 



3GPP TS 32.250 version 10.6.0 Release 10 



95 



ETSI TS 132 250 VI 0.6.0 (2013-01) 



r Field 


2G 


3G 


Description 


Call duration 


C 


C 


The chargeable duration of the connection of the incoming leg for successful calls, the 
holding time of the incoming leg for call attempts. 


Radio Chan. 
Requested 


Om 


- 


The type of radio traffic channel (full / half etc.) requested by the MS. 


Radio Chan. 
Used 


M 


- 


The type of radio channel actually used (full or half rate). 


Change of Rad. 
Chan. 


Oc 


- 


A list of changes each time stamped. 


Cause for 
termination 


M 


M 


The reason for the release of the connection. 


Diagnostics 


Om 


Om 


A more detailed reason for the release of the connection. 


Call reference 


M 


M 


A local identifier distinguishing between transactions on the same MS 


Sequence no. 


C 


C 


Partial record sequence number, only present in case of partial records. 


Record 
extensions 


Oc 


Oc 


A set of network / manufacturer specific extensions to the record, when available. 


GsmSCF 
address 


M 


M 


Identifies the CAMEL server serving the subscriber. 


Service key 


C 


C 


The CAMEL service logic to be applied. 


Network call 
reference 


M 


M 


An identifier to correlate transactions on the same call taking place in different network 
nodes. 


MSC Address 


M 


M 


This field contains the E.I 64 number assigned to the MSC that generated the network 
call reference. 


Default call 
handling 


Oc 


Oc 


Indicates whether or not a CAMEL call encountered default call handling. This field shall 
be present only if default call handling has been applied. 


Speech Version 
Supported 


Om 


- 


Speech version supported by the MS with highest priority indicated by MS 


Speech Version 
Used 


Om 


- 


Speech version used for that call 


Number of DP 
encountered 


Om 


Om 


Number that counts how often armed detection points (TDP and EDP) were encountered. 
Sum of all DPs encountered in this call. 


Level of CAMEL 
service 


Om 


Om 


Indicator for the complexity of the CAMEL feature used. 


Free format Data 


C 


C 


This field contains data sent by the gsmSCF in the Furnish Charging Information (FCI) 
message(s). The data can be sent either in one FCI message or several FCI messages 
with append indicator. 


CAMEL call leg 
information 


C 


C 


Set of CAMEL information lEs. Each of these lEs contains information related to one 
outgoing CAMEL call leg. 


CAMEL 

Destination 

Number 






Destination modified by camel service. 


Translated 
Number 






Called number after digit translation within the MSC. 


Connected 
Number 






Number of connected party if different from 'CAMEL Destination Number'. 


Roaming 
Number 






MSRN to route this leg (if applicable). 


MSC outgoing 
TKGP 






Trunk on which the leg leaves the MSC. 


Seizure Time 






Time of traffic channel seizure for this leg. 


Answer Time 






Time when the answer message is received for this leg. 


Release Time 






Time when the leg is released or moved into another call segment. 


Call Duration 






Time between answer and release timestamp of this leg. 


Additional Chg. 
Info 






Charge/no charge indicator and additional charging parameters, when available. 


Free Format 
Data 






If received in the FCI message from SCF. 


Free Format 
Data Append 






If received in the FCI message from SCF. 


Free Format 
Data 2 






If provided in the FCI message for a 2"" service. 


Free Format 
Data Append 2 






If provided in the FCI message for a 2™ service. 


Diagnostics 






Detailed reason for disappearing of the leg in this call segment. 


Cause for 
Termination 






The reason for disappearing of the leg in this call segment. 
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i Field 


2G 


3G 


Description 


Default Call 
Handling 2 






Present if a 2"" service (DPS) is triggered. 


gsm-SCF 
Address 2 






Present if a 2™ service (DPS) is triggered. 


Service Key 2 






Present if a 2"" service (DPS) is triggered. 


Free Format 
Data Incoming 2 






If provided in the FCI message for a 2"" service. 


Free Format 
Data Append 
Incoming 2 






If provided in the FCI message for a 2™ service. 


Location Routing 
Number (LRN) 






For Number Portability feature, not available in 20 records. 


LRN Source 
Indicator 






Source of the LRN, not available in 2G records. 


LRN Query 
Status Indicator 






Status of Number Portability query, not available in 2G records. 


JIP Parameter 






Jurisdiction Information Parameter, not available in 20 records. 


JIP Source 
Indicator 






The source of the JIP, not available in 20 records. 


JIP Query Status 
Indicator 






Status of Number Portability query, not available in 20 records. 


Free Format 
Data Append 
Indicator 


C 


C 


Indicator if free format data from this CDR is to be appended to free format data in 
previous partial CDR. Shall be present only if CAIVIEL id applied. 


System Type 




M 


This field indicates the use of OERAN, UTRAN (or a value of unknown) of the incoming 
leg. This field is present when either the UTRAN or OERAN air-interface is used on call 
set-up. For an open CDR in a 20 NE (responsible for the CDR), the field is not present 
(even if the call is handed off to a 30 air interface). For a CDR in a 30 NE (responsible for 
the CDR), the value unknown shall be used after handover. 


Partial Record 
Type 


- 


Qc 


Indicates the event (time limit etc.) that caused the generation of a partial record. 


Redial Attempt 


Qc 


Qc 


Indicates to the network that a call is the result of a redial attempt to switch from speech 
to multimedia or vice-versa 
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6.1 .3.24 gsmSCF initiated CAMEL CPH call attempt 

If the generation of these records is enabled then an MOC record shall be created for each gsmSCF initiated call attempt 
and for new parties in new call segments, which are created in a new call dialogue. Examples for call situations where 
this type of record applies are the following: 

gsmSCF initiated call segment association (new call): 

There is only one call segment. It contains the outgoing leg, which is created via CPH initiate call attempt 

operation (ICA). 

- This outgoing leg can be connected to an SRF, which is recorded in the same record in the field 'Camel Call 
Leg Information'. 

gsmSCF initiated new party in an already established gsmSCF initiated CAP dialogue (new leg): 
In a new call dialogue a further call leg in a new call segment is initiated via ICA operation. 

- This call segment contains one outgoing leg, which can be connected to an SRF. This leg and if used the SRF 
are recorded in the record for this call segment in the field 'Camel Call Leg Information'. 

- This leg can be connected to the other outgoing leg. This would terminate the call segment and thus the call 
record. The 'Cause for Termination' indicates the reason for disappearing of the leg in this call segment. The 
Timestamps ('Call Duration', 'Release Time', etc.) are filled in. The record of the call segment the leg is 
moved to records the leg in a further field 'Camel Call Leg Information'. 

- The other leg could be connected to this leg which is recorded by adding a further field 'Camel Call Leg 
Information'. 

Record fields for an incoming leg do not exist, because there is no incoming leg in the call segment this record is 
created for. 

Table 6.1.3.24: MOC CPH record (gsmSCF initiated) 



Field 


2G 


3G 


Description 


Record Type 


M 


M 


Mobile originated. 


Served MSISDN 


Om 


Om 


The number of the initiating party. "Calling Party Number" as received in the 
ICA operation. 


Called Number 


M 


M 


The address of the called party. 


Recording Entity 


M 


M 


The E.164 number of the visited MSC producing the record. 


Basic service 


M 


M 


Bearer or teleservice employed, 'speech' in case of CAMEL CPH calls. 


Cause for termination 


M 


M 


The reason for the release of the connection. 


Diagnostics 


Om 


Om 


A more detailed reason for the release of the connection. 


Call reference 


M 


M 


A local identifier distinguishing between transactions on the same MS 


Sequence no. 


C 


C 


Partial record sequence number, only present in case of partial records. 


Record extensions 


Oc 


Oc 


A set of network / manufacturer specific extensions to the record, when 
available. 


GsmSCF address 


C 


C 


Identifies the CAMEL server serving the subscriber (network call reference). 


Network call reference 


M 


M 


An identifier to correlate transactions on the same call taking place in different 
network nodes. 


MSC Address 


M 


M 


This field contains the E.164 number assigned to the MSC that generated the 
record. 


Number of DP 
encountered 


Oc 


Oc 


Number that counts how often armed detection points (TDP and EDP) were 
encountered. Sum of all DPs encountered in this call. 


Level of CAIVIEL service 


Oc 


Oc 


Indicator for the complexity of the CAMEL feature used. 


CAMEL call leg 
information 


C 


C 


Set of CAMEL information lEs. Each of these lEs contains information related 
to one outgoing CAMEL call leg. 


CAIVIEL Destination 
Number 






Destination as received in the ICA operation. 


Translated Number 






Called number after digit translation within the MSC. 


Connected Number 






Number of connected party if different from 'CAMEL Destination Number'. 


Roaming Number 






MSRN to route this leg (if applicable). 


IVISC outgoing TKGP 






Trunk on which the leg leaves the MSC. 


Seizure Time 






Time of traffic channel seizure for this leg. 


Answer Time 






Time when the answer message is received for this leg. 


Release Time 






Time when the leg is released or moved into another call segment. 


Call Duration 






Time between answer and release timestamp of this leg. 
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f Field 


2G 


3G 


Description 


Additional Chg. Info 






Charge/no charge indicator and additional charging parameters, when 
available. 


Free Format Data 






If received in the FCI message from SCF. 


Free Format Data Append 






If received in the FCI message from SCF. 


Free Format Data 2 






If provided in the FCI message for a 2"" service. 


Free Format Data Append 
2 






If provided in the FCI message for a 2"° service. 


Diagnostics 






Detailed reason for disappearing of the leg in this call segment. 


Cause for Termination 






The reason for disappearing of the leg in this call segment. 


Default Call Handling 2 






Present if a 2"" service (DPS) is triggered. 


gsm-SCF Address 2 






Present if a 2"° service (DPS) is triggered. 


Service Key 2 






Present if a 2"° service (DPS) is triggered. 


Free Format Data 
Incoming 2 






If provided in the FCI message for a 2"" service. 


Free Format Data Append 
Incoming 2 






If provided in the FCI message for a 2"'' service. 


Location Routing Number 
(LRN) 






For Number Portability feature, not available in 2G records. 


LRN Source Indicator 






Source of the LRN, not available in 2G records. 


LRN Query Status 
Indicator 






Status of Number Portability query, not available in 2G records. 


JIP Parameter 






Jurisdiction Information Parameter, not available in 2G records. 


JIP Source Indicator 






The source of the JIP, not available in 2G records. 


JIP Query Status Indicator 






Status of Number Portability query, not available in 2G records. 


Partial Record Type 


- 


Qc 


Indicates the event (time limit etc.) that caused the generation of a partial 
record. 
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6.1 .3.25 New Call Segment in a MO, CF and MT CAMEL Dialogue 

If the generation of these records is enabled then an MOC record shall be created for call segments without incoming 
leg, generated by a CAMEL dialogue for mobile originated, call forwarding or mobile terminating call attempts. 
Examples for call situations where this type of record applies are the following: 

Additional call segment, which is created by means of a 'SplitLeg' operation or ICA (new party) operation. 

- This call segment contains one outgoing leg, which can be connected to an SRF. This leg and if used the SRF 
are recorded in the record for this call segment in the field 'Camel Call Leg Information'. 

- This leg can be connected to the other outgoing leg. This would terminate the call segment and thus the call 
record. The 'Cause for Termination' indicates the reason for disappearing of the leg in this call segment. The 
Timestamps ('Call Duration', 'Release Time', etc.) are filled in. The record of the call segment the leg is 
moved to records the leg in a further field 'Camel Call Leg Information'. 

- The other leg could be connected to this leg which is recorded by adding a further field 'Camel Call Leg 
Information'. 

Call segment where the incoming leg disappeared (e.g. due to SplitLeg or DisconnectLeg operation). A record of 
this type is generated if partial records are generated. 

Although an incoming leg does not exists, the 'IMSI', the 'IMEI' and the 'Service Key' is recorded in the main body. 

Table 6.1.3.25: MOC CPH record (new call segment) 



r Field 


2G 


3G 


Description 


Record Type 


M 


M 


Mobile originated. 


Served IMSI 


M 


M 


IMSI of the served party ('calling party' in case of MOC, 'forwarding party' in case 
of call forwarding respectively 'called party' in case of MIC). 


Served IMEI 


C 


C 


IMEI of the served ME, if available ('calling party' in case of MOC, 'forwarding 
party' in case of call forwarding respectively 'called party' in case of MIC). 


Served MSISDN 


Om 


Om 


The MSISDN of the served party ('calling party' in case of MOC, 'forwarding party' 
in case of call forwarding respectively 'called party' in case of MTC). 


Called Number 


M 


M 


The address of the called party. 


Recording Entity 


M 


M 


The E.164 number of the visited MSC producing the record. 


Basic service 


M 


M 


Bearer or teleservice employed, 'speech' in case of CAMEL CPH calls. 


Supp. Services 


C 


C 


Supplementary services invoked as a result of this connection. This field shall be 
present when one or more supplementary services have been invoked. 


Cause for termination 


M 


M 


The reason for the release of the connection. 


Diagnostics 


Om 


Om 


A more detailed reason for the release of the connection. 


Call reference 


M 


M 


A local identifier distinguishing between transactions on the same MS 


Sequence no. 


C 


C 


Partial record sequence number, only present in case of partial records. 


Record extensions 


Oc 


Oc 


A set of network / manufacturer specific extensions to the record, when available. 


GsmSCF address 


C 


C 


Identifies the CAMEL server serving the subscriber. 


Service Key 


C 


C 


The CAMEL service logic to be applied. 


Network call reference 


M 


M 


An identifier to correlate transactions on the same call taking place in different 
network nodes. 


MSC Address 


M 


M 


This field contains the E.164 number assigned to the MSC that generated the 
network call reference. 


Default call handling 


Oc 


Oc 


Indicates whether or not a CAMEL call encountered default call handling. This 
field shall be present only if default call handling has been applied. 


Number of DP 
encountered 


Oc 


Oc 


Number that counts how often armed detection points (TDP and EDP) were 
encountered. Sum of all DPs encountered in this call. 


Level of CAMEL service 


Oc 


Oc 


Indicator for the complexity of the CAMEL feature used. 
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W Field 


2G 


3G 


Description 


CAMEL call leg 
information 


C 


C 


Set of CAIVIEL information lEs. Each of these lEs contains information related to 
one outgoing CAMEL call leg. 


CAIVIEL Destination 
Number 






Destination as received in the ICA operation. 


Translated Number 






Called number after digit translation within the MSC. 


Connected Number 






Number of connected party if different from 'CAMEL Destination Number'. 


Roaming Number 






MSRN to route this leg (if applicable). 


MSC outgoing TKGP 






Trunk on which the leg leaves the MSC. 


Seizure Time 






Time of traffic channel seizure for this leg. 


Answer Time 






Time when the answer message is received for this leg. 


Release Time 






Time when the leg is released or moved into another call segment. 


Call Duration 






Time between answer and release timestamp of this leg. 


Additional Chg. Info 






Charge/no charge indicator and additional charging parameters, when available. 


Free Format Data 






If received in the FCI message from SCF. 


Free Format Data 
Append 






If received in the FCI message from SCF. 


Free Format Data 2 






If provided in the FCI message for a 2™ service. 


Free Format Data 
Append 2 






If provided in the FCI message for a 2"" service. 


Diagnostics 






Detailed reason for disappearing of the leg in this call segment. 


Cause for Termination 






The reason for disappearing of the leg in this call segment. 


Default Call Handling 2 






Present if a 2"" service (DPS) is triggered. 


gsm-SCF Address 2 






Present if a 2"" service (DPS) is triggered. 


Service Key 2 






Present if a 2"^ service (DPS) is triggered. 


Free Format Data 
Incoming 2 






If provided in the FCI message for a 2"" service. 


Free Format Data 
Append Incoming 2 






If provided in the FCI message for a 2™ service. 


Location Routing 
Number (LRN) 






For Number Portability feature, not available in 2G records. 


LRN Source Indicator 






Source of the LRN, not available in 2G records. 


LRN Query Status 
Indicator 






Status of Number Portability query, not available in 20 records. 


JIP Parameter 






Jurisdiction Information Parameter, not available in 2G records. 


JIP Source Indicator 






The source of the JIP, not available in 2G records. 


JIP Query Status 
Indicator 






Status of Number Portability query, not available in 2G records. 


Partial Record Type 


- 


Qc 


Indicates the event (time limit etc.) that caused the generation of a partial record. 
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6.1 .3.26 Mobile originated call forwarding attempt (CAMEL CPH adapted version) 

If the MSC / gsmSCF is able to provide CAMEL CPH services, this kind of record shall replace records according to 
section "6.1.3.3 Mobile originated call forwarding attempt". This applies to all mobile originated call forwarding 
attempts, even if no CPH operations are used in the individual call. 

If the generation of MOC records is enabled in the forwarding MSC then the forwarding MSC shall produce an MOC 
record for the forwarded-leg of the call. 

If further legs in new call segments are generated by this CAMEL dialogue, they are recorded in CDRs of type 
"6.L3.25 New Call Segment in a MO, CF or MX CAMEL Dialogue". 

Connection of a further leg to this call segment is recorded by adding a further field 'Camel Call Leg Information'. 
Optionally a partial record may be generated. 

Table 6.1.3.26: MOC, call forwarding record (CAMEL CPH adapted version) 



Field 


2G 


3G 


Description 


Record Type 


M 


M 


Mobile originated. 


Served IMSI 


M 


M 


IMSI of the forwarding party. 


Served MSISDN 


Cm 


Om 


The MSISDN of the forwarding party. 


Calling Number 


Oc 


Oc 


The address of the calling party. 


Called Number 


M 


M 


The address of the "forwarded-to" party. 


Recording Entity 


M 


M 


The E.164 number of the forwarding MSC 


Incoming TKGP 


Cm 


Om 


The MSC trunk group on which the call originated at the forwarding MSC. 


Basic service 


C 


C 


'speech' in case of CAMEL CPH, not always available e.g. in case of call 
forwarding unconditional. 


Supplementary 
Services 


C 


C 


Supplementary services invoked as a result of this connection, if this information is 
available to the forwarding node. This field shall be present when one or more 
supplementary services have been invoked. 


Event time stamps: 


c 
c 

Cm 


c 
c 

Om 


Seizure time: time of incoming traffic channel seizure (for unsuccessful call 

attempts) 

Answer time: time of answer (for successful calls) 

Release time: time of traffic channel release 


Call duration 


C 


C 


The chargeable duration of the connection for successful calls, the holding time of 
call attempts. 


Cause for termination 


M 


M 


The reason for the release of the connection. 


Diagnostics 


Cm 


Om 


A more detailed reason for the release of the connection. 


Call reference 


M 


M 


A local identifier distinguishing between transactions on the same MS 


Sequence no. 


C 


C 


Partial record sequence number, only present in case of partial records. 


Record extensions 


Oc 


Oc 


A set of network/ manufacturer specific extensions to the record, when available. 


GsmSCF address 


C 


C 


Identifies the CAMEL server serving the subscriber. 


Service key 


c 


C 


The CAMEL service logic to be applied. 


Network call reference 


c 


C 


An identifier to correlate transactions on the same call taking place in different 
network nodes. 


MSC Address 


c 


c 


This field contains the E.164 number assigned to the MSC that generated the 
network call reference. 


CAMEL initiated CF 
indicator 


Oc 


Oc 


Indicates that the CAMEL server initiated call forwarding. Not available in case of 
gsm call forwarding. 


Default call handling 


Oc 


Oc 


Indicates whether or not a CAMEL call encountered default call handling. This field 
shall be present only if default call handling has been applied. 


Number of DP 
encountered 


Oc 


Oc 


Number that counts how often armed detection points (TDP and EDP) were 
encountered. Sum of all DPs encountered in this call. 


Level of CAMEL 
service 


Oc 


Oc 


Indicator of the complexity of the CAMEL feature used. 


Free format Data 


C 


C 


This field contains data sent by the gsmSCF in the Furnish Charging Information 
(FCI) messages. The data can be sent either in one FCI message or several FCI 
messages with append indicator. 
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r Field 


2G 


3G 


Description 


CAMEL call leg 
information 


C 


C 


Set of CAMEL information lEs. Each of these lEs contains information related to 
one outgoing CAMEL call leg. 


CAIVIEL Destination 
Number 






Destination modified by CAMEL service. 


Translated Number 






Called number after digit translation within the MSC. 


Connected Number 






Number of connected party if different from 'CAMEL Destination Number'. 


Roaming Number 






MSRN to route this leg (if applicable). 


IVISC outgoing TKGP 






Trunk on which the leg leaves the MSC. 


Seizure Time 






Time of traffic channel seizure for this leg. 


Answer Time 






Time when the answer message is received for this leg. 


Release Time 






Time when the leg is released or moved into another call segment. 


Call Duration 






Time between answer and release timestamp of this leg. 


Additional Chg. Info 






Charge/no charge indicator and additional charging parameters, when available. 


Free Format Data 






If received in the FCI message from SCF. 


Free Format Data 
Append 






If received in the FCI message from SCF. 


Free Format Data 2 






If provided in the FCI message for a 2™ service. 


Free Format Data 
Append 2 






If provided in the FCI message for a 2™ service. 


Diagnostics 






Detailed reason for disappearing of the leg in this call segment. 


Cause for Termination 






The reason for disappearing of the leg in this call segment. 


Default Call Handling 2 






Present if a 2™ service (DPS) is triggered. 


gsm-SCF Address 2 






Present if a 2™ service (DPS) is triggered. 


Service Key 2 






Present if a 2"" service (DPS) is triggered. 


Free Format Data 
Incoming 2 






If provided in the FCI message for a 2™ service. 


Free Format Data 
Append Incoming 2 






If provided in the FCI message for a 2™ service. 


Location Routing 
Number (LRN) 






For Number Portability feature, not available in 2G records. 


LRN Source Indicator 






Source of the LRN, not available in 2G records. 


LRN Query Status 
Indicator 






Status of Number Portability query, not available in 2G records. 


JIP Parameter 






Jurisdiction Information Parameter, not available in 2G records. 


JIP Source Indicator 






The source of the JIP, not available in 2G records. 


JIP Query Status 
Indicator 






Status of Number Portability query, not available in 2G records. 


Free format data 
append indicator 


C 


C 


Indicator if free format data from this CDR is to be appended to free format data in 
previous partial CDR. Shall be present only if CAMEL is applied. 


Partial Record Type 


- 


Qc 


Indicates the event (time limit etc.) that caused the generation of a partial record. 



£75/ 



3GPP TS 32.250 version 10.6.0 Release 10 



103 



ETSI TS 132 250 VI 0.6.0 (2013-01) 



6.1 .3.27 Terminating CAMEL call attempt (CAMEL CPH adapted version) 

If the MSC / gsmSCF is able to provide CAMEL CPH services, this kind of record shall replace records according to 
section "6.1.3.18 Terminating CAMEL call attempt". This applies to all terminating CAMEL call attempts, even if no 
CPH operations are used in the individual call. 

If the generation of these records is enabled, a terminating CAMEL call attempt record shall be generated for each call 
involving CAMEL CPH operations. The record is generated in the GMSC/gsmSSF carrying out the terminating 
CAMEL call handling and in the MSC server/gsmSSF carrying out the visited terminating CAMEL call attempt. 

If further legs in new call segments are generated by this CAMEL dialogue, they are recorded in CDRs of type 
"6.1.3.25 New Call Segment in a MO, CF or MT CAMEL Dialogue". 

Table 6.1.3.27: Terminating CAMEL record (CPH adapted version) 



r Field 


2G 


3G 


Description 


Record Type 


M 


M 


Terminating CAMEL interrogation. 


Served IMSI 


M 


M 


IMSI of the called party 


Served MSISDN 


Om 


Om 


The MSISDN of the called party. 


Recording Entity 


M 


M 


The E.164 number of the GMSC. 


Interrogation time 
stamp 


M 


M 


Time at which the interrogation was invoked. 


GsmSCF Address 


M 


M 


The CAMEL server serving the subscriber. 


Service key 


M 


M 


The CAMEL service logic to be applied. 


Network call 
reference 


M 


M 


An identifier to correlate transactions on the same call taking place in different 
network nodes. 


MSC Address 


M 


M 


This field contains the E.1 64 number assigned to the MSC that generated the 
network call reference. 


Default call handling 


Oc 


Oc 


Indicates whether or not a CAMEL call encountered default call handling. This field 
shall be present only if default call handling has been applied. 


Record extensions 


Oc 


Oc 


A set of network/ manufacturer specific extensions to the record, when available. 


Called Number 


M 


M 


The address of the called party as received by the GMSC/gsmSSF. 


Calling Number 


C 


C 


The address of the calling party, if available. 


Incoming TKGP 


Om 


Oc 


The GMSC trunk group on which the call originated. If available in 3G, this 
parameter shall be supplied. 


Event time stamps: 


C 
C 

Om 


C 
C 

Om 


Seizure time: time of incoming traffic channel seizure (for unsuccessful call 

attempts) 

Answer time: time of answer (for successful calls) 

Release time: time of traffic channel release 


Call duration 


C 


C 


The chargeable duration of the connection for successful calls, the holding time of 
call attempts. 


Cause for termination 


M 


M 


The reason for the release of the connection. 


Diagnostics 


Om 


Om 


A more detailed reason for the release of the connection. 


Call reference 


M 


M 


A local identifier distinguishing between transactions on the same MS 


Sequence no. 


C 


C 


Partial record sequence number, only present in case of partial records. 


Number of DP 
encountered 


Oc 


Oc 


Number that counts how often armed detection points (TDP and EDP) were 
encountered. Sum of all DPs encountered in this call. 


Level of CAMEL 
service 


Oc 


Oc 


Indicator of the complexity of the CAMEL feature used. 


Free format Data 


C 


C 


This field contains data sent by the gsmSCF in the Furnish Charging Information 
(FCI) message(s). The data can be sent either in one FCI message or several FCI 
messages with append indicator. 
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r Field 


2G 


3G 


Description 


CAMEL call leg 
information 


C 


C 


Set of CAMEL information lEs. Each of these lEs contains information related to one 
outgoing CAMEL call leg. 


CAMEL Destination 
Number 






Destination as received in the ICA operation or overwritten by TDP3. 


Translated Number 






Called number after digit translation within the MSC. 


Connected Number 






Number of connected party if different from 'CAMEL Destination Number'. 


Roaming Number 






MSRN or B-party (if applicable). 


MSC outgoing TKGP 






Trunk on which the leg leaves the MSC. 


Seizure Time 






Time of traffic channel seizure for this leg. 


Answer Time 






Time when the answer message is received for this leg. 


Release Time 






Time when the leg is released or moved into another call segment. 


Call Duration 






Time between answer and release timestamp of this leg. 


CAMEL Init CF 
Indicator 






Indicates that the CAMEL server initiated call forwarding. 


Additional Chg. Info 






Charge/no charge indicator and additional charging parameters, when available. 


Free Format Data 






If received in the FCI message from SCF. 


Free Format Data 
Append 






If received in the FCI message from SCF. 


Free Format Data 2 






If provided in the FCI message for a 2™ service. 


Free Format Data 
Append 2 






If provided in the FCI message for a 2™ service. 


Diagnostics 






Detailed reason for disappearing of the leg in this call segment. 


Cause for 
Termination 






The reason for disappearing of the leg in this call segment. 


Default Call Handling 
2 






Present if a 2™ service (DPS) is triggered. 


gsm-SCF Address 2 






Present if a 2™ service (DPS) is triggered. 


Service Key 2 






Present if a 2™ service (DPS) is triggered. 


Free Format Data 
Incoming 2 






If provided in the FCI message for a 2™ service. 


Free Format Data 
Append Incoming 2 






If provided in the FCI message for a 2™ service. 


Location Routing 
Number (LRN) 






For Number Portability feature, not available in 2G records. 


LRN Source Indicator 






Source of the LRN, not available in 2G records. 


LRN Query Status 
Indicator 






Status of Number Portability query, not available in 2G records. 


JIP Parameter 






Jurisdiction Information Parameter, not available in 2G records. 


JIP Source Indicator 






The source of the JIP, not available in 2G records. 


JIP Query Status 
Indicator 






Status of Number Portability query, not available in 2G records. 


Free format data 
append indicator 


C 


c 


Indicator if free format data from this CDR is to be appended to free format data in 
previous partial CDR. 


MSC server indication 


c 


c 


Indication if the CAMEL call handling is active in the MSC server. 


Partial Record Type 


- 


Qc 


Indicates the event (time limit etc.) that caused the generation of a partial record. 
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6.1 .3.28 SRVCC MSC Call handling in MSC server enhanced for SRVCC 

If the generation of these records is enabled then a MSC-SRVCC record shall be created for each voice call transfer 
from IMS domain to CS domain, for voice calls anchored in the IMS. These MSC-SRVCC records shall be produced in 
the enhanced MSC Server enhanced for SRVCC. 

Table 6.1.3.28: MSC-SRVCC record 



Field 


Category 


Description 


Record Type 


M 


MSC-SRVCC 


Served IMSI 


M 


IMSI of PS to CS Request. 


Served IMEI 


C 


Mobile Equipment Identity (IMEI, IMEISV) of the UE, if available 


Served MSISDN 


M 


The Correlation MSISDN of the PS to CS Request. 


Called Number 


M 


Session Transfer Number for Single Radio Voice Call Continuity (STN-SR) for 
transfer from PS to CS 


Recording Entity 


M 


The E.1 64 number of the enhanced MSC server producing the record. 


Outgoing TKGP 


Om 


The trunk group on which the call left the MSC, if available 


IMS Charging Identifier 


Om 


This parameter holds the IMS charging identifier (ICID) as generated by the 
enhanced MSC server with SIP interface. 


Location 


M 


Location of the UE after the successful SRVCC PS to CS Transfer. 


Change of Location 


Oc 


A list of changes in Location of the UE. Each time-stamped. 


Basic service 


M 


teleservice speech 


Supplementary Services 


C 


Supplementary services invoked as a result of this connection. This field shall 
be present when one or more supplementary services have been invoked. 


MS Classmark 


C 


Classmark of MM Context for E-UTRAN SRVCC in PS to CS Request 


Event time stamps: 


C 
C 

Om 


Transfer request time: time of PS to CS Request received by enhanced MSC 

server. 

Answer: time of answer received by enhanced MSC server on 

successful transfer 

Release time: time of traffic channel release 


ICS 12 active Flag 


C 


This field indicates that the MSC is IMS registered on the UE's behalf during 
the session 


Call duration 


M 


The chargeable duration of the connection for successful transferred call. 


Cause for termination 


M 


The reason for the release of the CS media. 


Diagnostics 


Om 


A more detailed reason for the release of the CS media 


Call reference 


M 


A local identifier distinguishing between transactions on the same MS 


Sequence no. 


C 


Partial record sequence number, only present in case of partial records. 


Record extensions 


Oc 


A set of network / manufacturer specific extensions to the record, when 
available. 


Partial Record Type 


Oc 


Indicates the event (time limit etc.) that caused the generation of a partial 
record. 



6.1 .3.29 SRVCC CS Emergency Call handling in MSC server enhanced for SRVCC 

If the generation of these records is enabled then a MSC-SRVCC Emergency record shall be created for each 
emergency call transfer from IMS domain to CS domain, for emergency calls anchored in the IMS. These MSC- 
SRVCC Emergency records shall be produced in the MSC server enhanced for SRVCC. 

Table 6.1.3.29: MSC-SRVCC Emergency record 



Field 


Category 


Description 


Record Type 


M 


MSC-SRVCC 


Served IMSI 


C 


IMSI of PS to CS Request, if available. 


Served IMEI 


C 


Mobile Equipment Identity (IMEI, IMEISV) of the UE, if available 


Served MSISDN 


C 


The Correlation MSISDN of the PS to CS Request, if available. 


Called Number 


M 


Emergency Session Transfer Number for SR VCC (E-STN-SR) for transfer 
from PS to CS. 


Recording Entity 


M 


The E.1 64 number of the enhanced MSC server producing the record. 


Outgoing TKGP 


Om 


The trunk group on which the call left the MSC, if available 


IMS Charging Identifier 


Om 


This parameter holds the IMS charging identifier (ICID) as generated by the 
enhanced MSC server with SIP interface. 


Location 


M 


Location of the UE after the successful SRVCC PS to CS Transfer. 


Change of Location 


Oc 


A list of changes in Location of the UE. Each time-stamped. 


Basic service 


M 


teleservice emergency 


MS Classmark 


C 


Classmark of MM Context for E-UTRAN SRVCC in PS to CS Request 
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Field 


Category 


Description 


Event time stamps: 


C 
C 

Om 


Transfer request time: time of PS to CS Request received by enhanced IVISC 

server. 

Answer: time of answer received by enhanced MSC server on 

successful transfer 

Release time: time of traffic channel release 


ICS 12 active Flag 


c 


This field indicates that the MSC is IIVIS registered on the UE's behalf during 
the session 


Call duration 


M 


The chargeable duration of the connection for successful transferred call. 


Cause for termination 


M 


The reason for the release of the CS media. 


Diagnostics 


Om 


A more detailed reason for the release of the CS media 


Call reference 


M 


A local identifier distinguishing between transactions on the same IVIS 


Sequence no. 


C 


Partial record sequence number, only present in case of partial records. 


Record extensions 


Oc 


A set of network / manufacturer specific extensions to the record, when 
available. 


Partial Record Type 


Oc 


Indicates the event (time limit etc.) that caused the generation of a partial 
record. 



6.1 .3.30 Mobile Terminating Roaming Forwarding call after successful Retrieval of 
Routeing Information (MTRF) handling in VMSC 

If the generation of these records is enabled then a MTRF record shall be created for each call re-routed from an 
original MSC to a destination MSC, resulting from Mobile Terminating Roaming Forwarding (MTRF) procedure. The 
MTRF records shall be produced in the MSC/VLR behaving as the Original MSC the call is re-routed from. 



Table 6.1.3.30: MTRF record 



Field 


3G 


Description 


Record Type 


M 


Mobile Terminating Roaming Forwarding. 


Served IMSI 


M 


IMSI of the called party. 


Served IMEI 


C 


IMEI of the called ME, if available. 


Served MSISDN 


Om 


The MSISDN of the called party. 


Calling Number 


C 


The number of the calling party if available. 


Roaming Number 


M 


The Mobile Station Roaming Number employed by the VMSC for routing to the new VMSC. 


Recording Entity 


M 


The E.1 64 number of the VMSC (i.e Old VMSC the call is re-routed from) 


Incoming TKGP 


Om 


The VMSC trunk group on which the call originated. 


Outgoing TKGP 


Oc 


The trunk group on which the call left the VMSC. 


Basic Service 


M 


teleservice employed 


Event time stamps: 


C 
C 

Om 


Seizure time: time of incoming trunk seizure 
Answer time: time of answer for successful calls 
Release time: time of outgoing trunk release 


Call duration 


M 


The chargeable duration of the connection if successful, the holding time of the incoming trunk 
for call attempts if unsuccessful. 


Cause for 
termination 


M 


The reason for the release of the call. 


Diagnostics 


Om 


A more detailed reason for the release of the connection. 


Call reference 


M 


A local identifier distinguishing between transactions at the same MS 


Sequence no. 


C 


Partial record sequence number, only present in case of partial records. 


Record extensions 


Oc 


A set of network/ manufacturer specific extensions to the record, when available. 


Partial Record 
Type 


Oc 


Indicates the event (time limit, etc.) that caused the generation of a partial record. 
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6.2 Data description for CS domain online charging 

CS domain charging is implemented by CAMEL techniques as described in 3GPP TS 23.078 [67] and 
3GPP TS 29.078 [73], i.e. it is outside the scope of the 3GPP 32-series charging TSs. 

6.2.1 Diameter message contents 

Void (refer to clause 6.2). 
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Annex A (informative): 

CDR File Transfer compliant with earlier 3GPP releases 

This group of TMN functions is concerned with the bulk transfer of call and event records from the NEF record 
filestore to the NEF. 

The call and event records shall be transferred from the NEF to the OSF by the use of FT AM protocol on X.25 or 
TCP/IP, and FTP or TFTP over TCP/IP. For further details of the use of FT AM see GSM 12.01 [405] and of the use of 
FTP see RFC 959 [400] and TFTP see [403]. 

In addition to the simple file transfer services provided by FT AM, peer-to-peer application process communication may 
be also be supported. The use of CMIS services for the uploading of files from the NEF to the OSF is specified in 
GSM 12.00 [406]. 
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Annex B (informative): 
Bibliography 

a) The 3GPP charging specifications 



3GPP TS 32.251: "Telecommunication management; Charging management; Packet Switched 
(PS) domain charging". 

3GPP TS 32.252: "Telecommunication management; Charging management; Wireless Local Area 
Network (WLAN) charging". 

3GPP TS 32.260: "Telecommunication management; Charging management; IP Multimedia 
Subsystem (IMS) charging". 

3GPP TS 32.270: "Telecommunication management; Charging management; Multimedia 
Messaging Service (MMS) charging". 

3GPP TS 32.271: "Telecommunication management; Charging management; Location Services 
(LCS) charging". 

3GPP TS 32.296: "Telecommunication management; Charging management; On-line Charging 
System (OCS) applications and interfaces". 

b) other charging specifications 

c) Common 3GPP specifications 

3GPP TS 22.101: "Service aspects; Service principles". 

3GPP TS 23.003: "Numbering, addressing and identification". 

3GPP TS 27.001 : "General on Terminal Adaptation Functions (TAP) for Mobile Stations (MS)". 

d) other Domain and Service specific 3GPP / ETSI specifications 
3GPPTS 23.009: "Handover procedures". 

3GPP TS 23.040: "Technical reaHzation of the Short Message Service (SMS)". 

3GPP TS 24.080: "Mobile radio Layer 3 supplementary service specification; Formats and 
coding". 

3GPP TS 49.031: "Location Services (LCS); Base Station System Apphcation Part LCS Extension 
(BSSAP-LE)". 

3GPP TS 29.002: "Mobile Application Part (MAP) specification". 

e) Relevant ITU Recommendations 

ITU-T Recommendation E. 164: "The international public telecommunication numbering plan". 

ITU-T Recommendation Q.767: "Application of the ISDN user part of CCITT Signalling System 
No.7 for international ISDN interconnections". 

ITU-T Recommendation X.25: "Interface between Data Terminal Equipment (DTE) and Data 
Circuit-terminating Equipment (DCE) for terminals operating in the packet mode and connected to 
public data networks by dedicated circuit". 

ITU-T Recommendation X. 121: "International numbering plan for public data networks". 

GSM 12.00: "Network Management (NM); Part 1: Objectives and structure of network 
management" . 
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Annex C (informative): 

Charging Support for Voice Call Continuity 

Voice Call Continuity is a home IMS application that provides capabilities to transfer voice calls between the CS 
domain and the IMS. VCC provides functions for voice call originations, voice call terminations and for Domain 
Transfers between the CS domain and the IMS. This feature is defined in 3GPP TS 23.206 [210]. 

The following principles apply to VMSC/GMSC that are capable of VCC: 

In case of CS Origination call with anchoring in the IMS, the Access Leg is charged as follows: Normal MOC CDR is 
generated by the VMSC with special handling. One example of special handling is to zero rate the CS resource usage. 
This can be performed using the "Service Key" parameter in the MOC Record indicating a VCC call. The CDRs 
generated within the IMS Domain to complete the anchoring mechanism are handled as specified in 3GPP TS 32.260 
[55]. 

In case of IMS origination call, the Access Leg is charged as follows: Normal IMS and IP-CAN (e.g. WLAN or 
GSM/GPRS) charging mechanism are applied. These mechanisms are defined in 3GPP TS 32.260 [55] and IP -CAN 
Middle Tier TS respectively. 

In case of Incoming call received via CS and routed to IMS, the Remote Leg is charged as follows: Normal MTC CDRs 
are generated by the GMSC of the terminating network with special handling. One example of special handling is to 
zero rate the CS resource usage. This can be performed using the "Service Key" parameter in the MTC Records 
indicating a VCC call. The CDRs generated within the IMS Domain to complete the Domain selection procedure are 
handled as specified in 3GPP TS 32.260 [55]. 

In case of Incoming call received via CS and routed to CS with anchoring, the Remote Leg is charged as follows: 
Normal MTC CDRs are generated by the GMSC and the VMSC in the terminating network with special handling. One 
example of special handling is to zero rate the CS resource usage. This can be performed using the "Service Key" 
parameter in the MTC Records indicating a VCC call. The CDRs generated within the IMS Domain to complete the 
anchoring procedure are handled as specified in 3GPP TS 32.260 [55]. 

In case of Incoming call received via IMS and routed to IMS, the Remote Leg is charged as follows: Normal IMS and 
IP -CAN (e.g. WLAN or GSM/GPRS) charging mechanism are applied. These mechanisms are defined in 3GPP TS 
32.260 [55] and IP-CAN Middle Tier TS respectively. 

In case of Incoming call received via IMS and routed to CS with anchoring, the Remote Leg is charged as follows: 
Normal MTC CDRs are generated by the GMSC or the VMSC in ther terminating network with special handling. One 
example of special handling is to zero rate the CS resource usage. This can be performed using the "Service Key" 
parameter in the MTC Records indicating a VCC call. The CDRs generated within the IMS Domain to complete the 
domain selection procedure are handled as specified in 3GPP TS 32.260 [55]. 

In case of Domain Transfer from IMS to CS, the Access Leg is charged as follows: Normal MOC CDR is generated by 
the VMSC of the new Access Leg with special handling. One example of special handling is to zero rate the CS 
resource usage. This can be performed using the "Service Key" parameter in the MOC Record indicating a VCC call. 
The IMS CDRs generated to perfom Domain Transfer are handled as specified in 3GPP TS 32.260 [55]. 

In case of Domain Transfer from CS to IMS, the Access Leg is charged as follows: The MOC CDRs of the Source- 
Access Leg (i.e. the Access leg previously established over CS) are closed when the Source Acces Leg is released 
following normal CDR closure associated with CS call release. The IMS CDRs generated on the new access Leg are 
handled as specified in 3GPP TS 32.260 [55]. 
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Annex D (informative): 
Change history 



Change history 


Date 


TSG# 


TSG Doc. 


CR 


Rev 


Subject/Comment 


Cat 


Old 


New 


Mar 2007 


SA 35 


SP-070039 


0010 


- 


Introduce CS charging implications of VCC 


B 


6.6.0 


7.0.0 


Mar 2007 


SA 35 


SP-070043 


0011 


- 


Add MCC MNC in Location/change of location field 


B 


6.6.0 


7.0.0 


Jun 2007 


SA 36 


SP-070268 


0013 


- 


Correction on MOC CDRs - Align witfi ITU ISUP Q.763 


A 


7.0.0 


7.1.0 


Dec 
2008 


SA_42 


- 


- 


- 


Upgrade to Release 8 


- 


7.0.0 


8.0.0 


Sep 
2009 


SA_45 


SP-090536 


0014 


- 


Correction to MO and MT SMS CDRs for SMS over SGs 


F 


8.0.0 


8.1.0 


Dec 
2009 


- 






- 


Update to Rel-9 version (MCC) 




8.1.0 


9.0.0 


Mar 2010 


SA 47 


SP-1 00040 


0016 


- 


Correction on System Type parameter 


F 


9.0.0 


9.1.0 


Mar 2011 


SA_51 


SP-1 10108 


0018 


1 


Introduction of new CDRs for SRVCC feature in enhanced MSC server - 
Alignment with 3GPP TS 23.216 


F 


9.1.0 


9.2.0 


2011-03 


- 


- 


- 


- 


Update to Rel-10 version (MCC) 




9.2.0 


10.0.0 


2011-03 


- 






- 


Correction of Update to Rel-10 version (MCC) 




10.0.0 


10.0.1 


2011-06 


SA_52 


SP-1 10281 


0020 


- 


Clarification on Mobile Originating Call Forwarding CDR generation when 
no 0-CSI 


F 


10.0.1 


10.1.0 


2011-09 


SA 53 


SP-1 10530 


0022 


1 


Correction on MT-LR CDR - Alignment with TS 23.271 


F 


10.1.0 


10.2.0 


2011-12 


SA 54 


SP-1 10709 


0024 


1 


Correction on MSC-SRVCC CDRs for SuppI services and location 


A 


10.2.0 


10.3.0 


Mar 201 2 


SA_55 


SP-1 20047 


0028 


1 


Correction for E-UTRAN location (TAI and E-CGI) on Location Update 
(VLR) record 


A 


10.3.0 


10.4.0 


Mar 201 2 


SA_55 


SP-1 20050 


0025 


1 


Correction on Charging for Mobile Terminating Roaming Forwarding 
(MTRF) - alignment with TS 23.01 8 


F 


10.3.0 


10.4.0 


Jun-2012 


SA-56 


SP-1 20360 


0030 


1 


Correction of CDRs for SRVCC 


A 


10.4.0 


10.5.0 


Dec- 
2012 


SA-58 


SP-1 20785 


0034 


- 


RIO CR 32250 Remove related ICID from MSC SRVCC and MSC 
SRVCC emergency 


A 


10.5.0 


10.6.0 
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